Re: Clarification regarding ManagedExecutorService in Rx Client




as much as I would love to work on JAX-RS 2.1.1, 2.2 or 3.0, actually this is impossible at the moment. The reason is that JAX-RS is to be migrated from Oracle to the Eclipse Foundation. At the moment, it is unclear under which conditions and in what timeframe a maintenance release of the JAX-RS Specification PDF could be published. Also at the moment, it is unclear if such a maintenance release would be standardized by the JCP, or by a different organization. I am sorry not to be able to give a better answer, but it is all in the hands of Oracle's lawyers and the PMC still.


I have CC'ed IBM's PMC member Kevin Suter. Maybe he has an updated schedule on this he is willing to share with you.


Regarding the question itself, the JAX-RS specification does not make any assumptions upon invoking users. In particular, a scenario where three users  / three threads share and extend one single "fiber" is not part of JAX-RS. Hence, the specification leaves this open intentionally but just says that context capture "has to work". Could you elaborate how such a scenario could look like, where three threads invoked by three different users have access to the same "fiber"?



EG JSR 370



From: [] On Behalf Of Andy McCright
Sent: Dienstag, 12. Dezember 2017 23:44
Subject: [jaxrs] Clarification regarding ManagedExecutorService in Rx Client


Hi Experts,


While working on the JAX-RS 2.1 implementation in Liberty, a colleague of mine discovered some inconsistent behavior related to the reactive client's CompletionStage with regard to executors.  He wrote me:



When a ManagedExecutorService is used as the default asynchronous execution facility for a CompletionStage created by a JAX-RS client's CompletionStageRxInvoker, the specification is currently unclear as to exactly when thread context should be captured for propagation to the CompletionStage and its dependent stages.
The ambiguity similarly exists when ManagedExecutorService is explicitly specified in any of the *Async methods. For example, completionStage.thenRunAsync(runnable, executor).

In discussions within our team, we have come to the conclusion that it makes sense for thread context capture to always (and only) be done at the point in time where CompletionStageRxInvoker.<method> is invoked to create the CompletionStage and at each point where CompletionStage.*Async is invoked to create a dependent stage.

Let's consider a scenario where code running as user1 uses the JAX-RS client to create a CompletionStage, and a subsequent block of code running as user2 adds a dependent stage, followed by another block of code running as user3, which adds another dependent stage.
This could be shown as:

Code running as user1 invokes:  stage1 = clientBuilder.executorService(managedExecService).build().target(uri).request().rx().method(...);
Code running as user2 invokes:  stage2 = stage1.handleAsync(function2);
Code running as user3 invokes:  stage3 = stage2.handleAsync(function3);

With our proposal, the spec would guarantee that function2 always runs as user2 and function3 always runs as user3, which we believe to best match the intent of the user.  Note that, lacking this behavior as proposed, it seems wrong to allow user2 or user3 to be able to add dependent stages that run as user1. Therefore, we would not want thread context capture to be done at alternate points, such as at the end of the execution of the previous stage.  We would like to see the spec updated to state this guarantee about thread context capture and transfer when using the JAX-RS client builder with ManagedExecutorService, such that users will be able to rely on a predictable and useful behavior.



Would it be possible to clarify this in the spec - perhaps as part of a maintenance release?  If it would help, I could draft up some text and submit a pull request.


Thanks in advance for your review,



J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448


Join to automatically receive all group messages.