[jira] [Commented] (CXF-8242) Stop blocking executor thread on microprofile rest asynchronous call

["Andriy Redko (Jira)" <ji...@apache.org>]

    [ 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)