[jira] [Assigned] (CXF-8626) async http client may handle response by multiple threads on work queue

["Freeman Yue Fang (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Freeman Yue Fang reassigned CXF-8626:
-------------------------------------

    Assignee: Freeman Yue Fang

> 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
>
> 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)