[
https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063032#comment-17063032
]
Andriy Redko commented on CXF-8242:
-----------------------------------
Hey [~baiglin] ,
Thanks for bringing up this issue. I had a chance to look at it but
unfortunately the fix is not as easy as it sounds. To briefly summarize the
problem, MPRestClientCallback is a Future<?> itself, with a completely own
lifecycle. What MPRestClientCallback tries to do at the moment is attempting to
convert itself (Future<?>) to CompletableFuture<?> (which is basically a
blocking call to get()). By introducing an ad-hoc CompletableFuture<?>, as you
suggesting, would work for most cases, but:
- introduces parallel completion chain (Future<?> + CompletableFuture<?>)
- does not properly propagate cancellation (even now the MPRestClientCallback
does not handle it properly)
I understand that this clarification does not solve the problem but just wanted
to share the findings with you. I am looking at a couple of options right now,
will try to suggest an acceptable fix shortly.
Thank you.
> Stop blocking executor thread on microprofile rest asynchronous call
> ----------------------------------------------------------------------
>
> Key: CXF-8242
> URL: https://issues.apache.org/jira/browse/CXF-8242
> Project: CXF
> Issue Type: Bug
> Components: MicroProfile
> Affects Versions: 3.3.5
> Reporter: Baptiste AIGLIN
> Assignee: Andriy Redko
> Priority: Critical
> Attachments: cxf-microprofile.zip
>
>
> Hello, while digging into the way implementation for microprofile was done to
> understand how I can override the default executor and how it is used behind
> the scene, I found that the microprofile futures are actually created using
> CompletableFuture.supplyAsync using the given executor or default one defined
> by CXF and calling wait on it. If not mistaken this should block the executor
> thread until it is resumed by async handler. This is a major issue for us as
> we were expecting pure asynchronous processing to avoid defining executors
> with many threads.
> If everything I say is correct I have tried to implement a naive
> implementation creating a future using constructor that is not waiting but
> will be completed by asynchronous handler
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
