[ 
https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063163#comment-17063163
 ] 

Baptiste AIGLIN edited comment on CXF-8242 at 3/20/20, 8:28 AM:
----------------------------------------------------------------

Hi Andriy,

Many thanks for the explanation, so the idea would be to try having only one 
level of future without introducing new one on top? (Sounds easy saying it...). 

No chance on making the ClientCallback class extends CompletableFuture to have 
it implement the Future ? This could also benefit the Jax-ws :)

Much appreciated your findings, I am really interested so do not hesitate to 
post. Thanks


was (Author: baiglin):
Hi Andriy,

Many thanks for the explanation, so the idea would be to try having only one 
level of future without introducing new one on top? (Sounds easy saying it...). 

Much appreciated your findings.

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

Reply via email to