| Re: [jaxrs-dev] Client Filter Question |
Santiago, we simply have different view angels and visions. :-) Regarding your joke, yes, we actually want to include DI: That's why some guys, like Arjan and me, so badly want JAX-RS to mandate CDI ASAP. I know what the intention was back then and how REST servers worked back then. But the past is the past. REST architecutures have changed completely, turning the stack upside down, deprecating the "ancient" server products. So as of today I simply take the API and spec just literally (the written text, the actual behavior, but not the former intention of the authors). So what I take from this discussion back to the original author of the question is that it actually works but nobody intended to and so what he does currently is officially invalid. ;-) -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen On Jul 26, 2018, at 1:20 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote: 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 From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen Sent: Donnerstag, 26. Juli 2018 14:46 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 _______________________________________________ _______________________________________________ |