| Re: [jaxrs-dev] Client Filter Question |
I need to amend my answer after having had a second look into the JavaDocs. Unless we explicitly forbid something, this still is Java, so all what Java can do must allowed. How shall one know if the spec / Javadocs don't mention it? void abortWith(Response response)Abort the filter chain with a response. This method breaks the filter chain processing and returns the provided response back to the client. The provided response goes through the chain of applicable response filters. As an aborted request goes through the response chain just as a "real" response, and as a response filter gets hands on the request context, the request context seems to survive the abortion, hence it lives while the target host processes the request, hence is a valid target for operations. According to the API itself, it even seems to be allowed to abort the request even inside a response filter! Hence, I do not see any technical obstacle why we shouldn't explicitly allow to cancel a pending request "in-flight"? I tend to say that once it is done correctly by the user (my customer's example wasn't, as it cancels unconditionally -- the entry into the response filter should cancel the timer [one-cancels-theother), it actually would work even in existing JAX-RS containers. -Markus From: Markus KARG [mailto:markus@xxxxxxxxxxxxxxx] 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? 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. -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen 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 On Jul 24, 2018, at 3:47 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote: 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()); } }, 10_000); } Regards -Markus _______________________________________________ |