You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andriy Redko (Jira)" <ji...@apache.org> on 2020/04/01 01:11:00 UTC

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

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

Andriy Redko commented on CXF-8242:
-----------------------------------

[~coheigea] the tests should be all good now, it was all about timing issues. In the nutshell, when I did the refactoring, unintentionally the sequence of callback completion and handler invocation was impacted. I restored this behavior by insuring that handler is always called first, than callback completes. Thanks a lot for spotting this regression.

> 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.6, 3.2.13
>            Reporter: Baptiste AIGLIN
>            Assignee: Andriy Redko
>            Priority: Critical
>             Fix For: 3.4.0, 3.2.14, 3.3.7
>
>         Attachments: cxf-microprofile.zip
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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)