Santiago, I do not see CDI as third party, but Microprofile. One was a part of Java EE just as JAX-RS, the other was not (and not even has a certification process). In fact, the currently written text allows multi-thread use implicitly as it is common sense in Javadocs authoring to explicitly forbid such use, not to explicitly allow it. Otherwise you wouldn't be able to use most of the JRE. Javadocs for String does not even mention the word "thread" and you certainly won't doubt that it is thread-safe implicitly (simply due to its immutability). Example from HashMap's description: "Note that this implementation is not synchronized.". So until we forbid it, it is allowed. Regarding the race conditions: Yes, just as I said, that is up to the application programmer to take care of. With "it works" I meant that the abortion method is effective even after the request filter chain ended. -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen
Sent: Freitag, 27. Juli 2018 00:03
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Client Filter Question
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. And I want that too, but that is the point, CDI is included by reference, so in that sense it is a third-party API.
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). We should always go with what’s written, of course. But I’m confused now, are you saying that what is written allows or disallows the use case? Does it say that ClientRequestContext is thread safe?
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. ;-) Whether it works or not may depend on the filter chain in question. It’s easy to create potential race conditions between that TimerTask execution and other filters further down in the chain —e.g., a filter that wants to abort using a different response. 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? :-) Sent: Donnerstag, 26. Juli 2018 14:46
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Client Filter Question 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. 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()); _______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
|
