[
https://issues.apache.org/jira/browse/CXF-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058050#comment-17058050
]
Freeman Yue Fang commented on CXF-8239:
---------------------------------------
Hi [~baiglin],
Jira ticket should be used to track bugs or feature requests. For
questions/discussions, please send it to the mailing list.
Btw, I don't think we want to handle real requests in I/O dispatcher thread,
which ideally is one for each CUP core. We should let threads manged by cxf do
the heavy-lift/time-consuming job.
Anyway, if you wanna further discussion, please send mail to the mailing list.
Thanks!
Freeman
> Why AutomaticWorkQueue is used when providing an executor on asynchronous case
> ------------------------------------------------------------------------------
>
> Key: CXF-8239
> URL: https://issues.apache.org/jira/browse/CXF-8239
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.3.5
> Reporter: Baptiste AIGLIN
> Priority: Major
>
> When looking on introducing a dedicated Executor when performing asynchronous
> calls, we see that in the HttpConduit#WrappedOutputStream base class, when
> the handleResponseOnWorkqueue method is called, which seem to be the method
> call on all conduit implementations (synchronous URLConnectionHTTPConduit and
> AsyncHTTPConduit) when handling the response of asynchronous calls, if the
> forceWQ flag is used, even if we have set a dedicated TaskExecutor, we will
> still execute something in the Workqueue. So far with the name of the
> variable it makes sense, but why forcing it in case of async replies on the
> AsyncHTTPConduit#setHttpResponse ? This forces us to execute the call to our
> executor in the work queue thread instead of directly in the I/O dispatcher
> thread.
>
> Thanks for feedback!
> Baptiste
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
