[
https://issues.apache.org/jira/browse/CXF-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137988#comment-17137988
]
Andriy Redko commented on CXF-8303:
-----------------------------------
Hi [~baiglin], my apologies, took a bit longer to figure things out, there are
few outcomes:
* The async callback for MP Client is invoked in the context of CXF's internal
work queue thread (managed by AutomaticWorkQueueImpl). When future completes,
we have to free up this thread right away which justifies the need to use
*thenApplyAsync* + *executor*. If we don't do that, we could easily exhaust the
work pool by chaining time-consuming operations (unfortunately, we don't have
control over it if the future is exposed as is). I think this is right BUT ...
* This behavior appears to be *inconsistent* with other JAX-RS clients
(ClientImpl and WebClient), at least with respect to handling invocation
callbacks which happens in the context of CXF's internal work queue thread.
* And, as you rightly noticed, this behavior appears to be *inconsistent* with
JAX-WS async callbacks / handlers which indeed are invoked in the context of
CXF's internal work queue thread.
Now, the important part is MP Rest Client specification [1], it mandates the
invocation of the async method in the context of the provided executor service:
{code:java}
* Specifies the <code>ExecutorService</code> to use when invoking
* asynchronous Rest Client interface methods. By default, the executor
* service used is determined by the MP Rest Client implementation runtime.
{code}
I know that it does not solve your problem, but may be at least justifies the
need to offload the work to another pool, if we change the behavior we would
violate the specfication.
[1]
https://github.com/eclipse/microprofile-rest-client/blob/4f83c6b5cf6638b4dab409da4d5738df78d635c6/api/src/main/java/org/eclipse/microprofile/rest/client/RestClientBuilder.java#L170
> MP: Context propagation impossible using AsyncInvocationInterceptorFactory
> ---------------------------------------------------------------------------
>
> Key: CXF-8303
> URL: https://issues.apache.org/jira/browse/CXF-8303
> Project: CXF
> Issue Type: Bug
> Components: MicroProfile
> Reporter: Baptiste AIGLIN
> Assignee: Andriy Redko
> Priority: Major
> Attachments: cxf-context-reproducer.zip
>
>
> Hello!
> We are deeply working using the Microprofile rest client implementation of
> CXF and we have trouble with the context propagation between threads.
> We have implemented AsyncInvocationInterceptorFactory and use it to propagate
> threadLocal context on the receiving thread after an asynchronous call, but I
> found some problem due to this:
> * Call is performed from the main thread
> * Response is handled in the CXF work queue, that execute the interceptor
> chain and propagate the thread local context correctly
> * During the chain execution the response entity is set to notify the future
> but it then execute in the executor thread (By default ForkJoinPool)
> So the fact that the future is returned using the *Async method of the
> CompletableFuture makes the next stage to execute in the executor
> (ForkJoinPool) thread where the context was not propagated.
>
> I am not saying this is simple since it is not, but could it be possible to
> return the future itself rather than using the custom executor
> (ForkJoinPool), and instead use the custom executor the same way it is used
> for JAX-WS where I think it is set as Executor in the exchange and later
> retrieve by the conduit to perform the response execution ?
> Also we noticed due to this that as soon as the response is notified, the
> full interceptor chain is not yet executed and continue to execute in the
> workqueue thread while the next stage is starting to execute in the
> ForkJoinPool thread.
> I hope I was clear enough. I add a reproducer with the dummy solution I could
> come up with to see what I am asking is at least fixing the problem. Also I
> know a fix is already ongoing here
> https://issues.apache.org/jira/browse/CXF-8242 but is using
> thenApplyAsync(res -> (T)res[0], executor), so should not fix the problem.
> Thanks a lot
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
