[
https://issues.apache.org/jira/browse/CXF-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459606#comment-17459606
]
Andriy Redko commented on CXF-8626:
-----------------------------------
Thanks for the fix, [~ffang] , it seems like we may need to have for HttpClient
5 as well? I just realized it does not play well with chunked input ...
> async http client may handle response by multiple threads on work queue
> -----------------------------------------------------------------------
>
> Key: CXF-8626
> URL: https://issues.apache.org/jira/browse/CXF-8626
> Project: CXF
> Issue Type: Bug
> Reporter: Freeman Yue Fang
> Assignee: Freeman Yue Fang
> Priority: Major
> Fix For: 3.5.0, 3.4.6, 3.3.13
>
>
> In the AsyncHttpConduit, we have code like
> {code}
> protected synchronized void setHttpResponse(HttpResponse r) {
> httpResponse = r;
> if (isAsync) {
> //got a response, need to start the response processing now
> try {
> handleResponseOnWorkqueue(false, true);
> isAsync = false; // don't trigger another start on next
> block. :-)
> } catch (Exception ex) {
> //ignore, we'll try again on the next consume;
> }
> }
> notifyAll();
> }
> {code}
> which intends to spin only one threads to handle response, not matter how
> many blocks the response contains. However, in some cases, the isAsync field
> can be reset true by handleResponseAsync method, hence the second thread can
> be launched to handle the same response stream, so can mess up the response
> stream. Actually isAsync has already been initialized correctly when the
> first time to create AsyncWrappedOutputStream, so method handleResponseAsync
> shouldn't reset it.
> We can see this problem when enabling retransmit && chunklength<payload
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
