[
https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109194#comment-17109194
]
Baptiste AIGLIN commented on CXF-8242:
--------------------------------------
I should have been clearer, sorry, I meant from the response future object, in
jaxws, we can access the response context from the Response interface, but here
with the future, after the exchange is done, I cannot access anymore the
context linked to a given response. For synchronous case it is less tricky as I
think I can get it from the proxy object but in case of async, I dont see how
to access the callback after my call is performed (I could store the callback
in the interceptor chain but I would like to get it from the response object
itself)
> 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)