[
https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072282#comment-17072282
]
Andriy Redko edited comment on CXF-8242 at 4/1/20, 1:10 AM:
------------------------------------------------------------
[~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 ensuring that handler is always called first, than callback
completes. Thanks a lot for spotting this regression.
was (Author: reta):
[~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)
