Well, the method call *is* synchronous, but it passes the context to a newly spawned thread. If that is forbidden, we should clearly mention that in the JavaDocs (I could provide a PR). In fact is questionable why it shouldn't work already? As a response filter gets the request context, the context seem to live meanwhile. So why not allowing the cancellation?
Because none of this aligns with the original intent of a ClientRequestContext. Each filter is supposed to get it, use it and pass it along, not store it and update it later in the future. It is a mutable object which is not guaranteed to be thread safe, so calling a mutable method in that manner on a separate thread (at an "asynchronous time" in the future) is just wrong (perhaps the method name is misleading as it seems to execute an action rather than record an outcome, which I think was the original intent).
Regarding the use case, I see it differently. JAX-RS "NG" should be able to cancel running requests, independent of the actual use case. It would make JAX-RS more feature complete without the need to use third party APIs to products. For example, one could implement circuit breakers as JAX-RS features, which feels more familiar than any other solution.
Possibly, but circuit breakers are non-trivial and there are external solutions that people can use, so there’s something to be said about not reinventing the wheel. As for “more feature complete”, how do you define completeness? Should we include our own DI too? :-)
— Santiago
Sent: Donnerstag, 26. Juli 2018 14:46
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Client Filter Question Markus, Unless otherwise stated this type of method call should be synchronous. When a filter returns, its task is completed and the next filter runs, so this type of behavior is undefined and invalid. This use case should be tackled at a different level, using solutions like Hystrix, Failsafe or MicroProfile Fault Tolerance. — Santiago
I'd like to foward this question I received today. Opinions? Is it possible and valid to abort a running request using the exposed ClientRequestContext after the filter() method already exited? // aborts request when exceeding timeout of 10s @Override public void filter(ClientRequestContext requestContext) throws Exception { new Timer().schedule(new TimerTask() { @Override public void run() { requestContext.abortWith(Response.noContent().build());
|
