[
https://issues.apache.org/jira/browse/CXF-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058069#comment-17058069
]
Baptiste AIGLIN commented on CXF-8239:
--------------------------------------
Sorry I will do it right away, it was in case it could become something to fix,
I understand you do not want at all to handle the requests in the I/O
dispatcher, which is not the case if you submit your runnable in the executor
you provide, so I don't see the gain on wrapping the runnable to be executed in
the custom executor, and execute this runnable in the worqueue, to me it looks
like executing the runnable that actually process reply in the executor inside
the work queue. I don't understand why, sorry.
> 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)
