[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    [jira] [Commented] (HTTPCORE-638) SharedOutputBuffer calls endStream multiple times
From:       "ASF subversion and git services (Jira)" <jira () apache ! org>
Date:       2020-07-23 11:10:00
Message-ID: JIRA.13318368.1595291848000.109893.1595502600088 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/HTTPCORE-638?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163432#comment-17163432 ] \


ASF subversion and git services commented on HTTPCORE-638:
----------------------------------------------------------

Commit 41ff6a8f1f4d20e1233fdc3df543f921f41d856e in httpcomponents-core's branch \
refs/heads/master from malaysf [ \
https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=41ff6a8 ]

HTTPCORE-638: SharedOutputBuffer must trigger DataStreamChannel#endStream() once \
(#204)



> SharedOutputBuffer calls endStream multiple times
> -------------------------------------------------
> 
> Key: HTTPCORE-638
> URL: https://issues.apache.org/jira/browse/HTTPCORE-638
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 5.0
> Reporter: Malay Shah
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
> 
> Using `SharedOutputBuffer` in conjunction with `ContentOutputStream` can cause \
> `endStream` to be called multiple times on the `DataStreamChannel`. I've noticed \
> this happening in my code where I'm using something nearly identical \
> `AbstractClassicEntityProducer` (only difference is that I use my own thread to \
> produce the data). When this happens, the `HttpAsyncMainClientExec`'s \
> `messageCountDown` goes to zero and the exchange is considered completed but since \
> no response was processed, it results in a `cancel` callback. I should note that \
> this does not happen all the time but frequently enough when I'm calling into a \
> local web server. Here's how `endStream` ends up being called twice:
> * Once from the producer thread when it calls close on the `ContentOutputStream`
> * one from the call to `SharedOutputBuffer.flush` from \
> `OutputStreamClassicEntityProducer.produce`. From my understanding, this sequence \
> is legitimate as `OutputStreamClassicEntityProducer.produce` is called repeatedly, \
> and it can hold on to the DataStreamChannel to call into asynchronously (from the \
> comment in `AsyncDataProducer`). When I've seen this happen, both calls to \
> `endStream` happen within one or two milliseconds of each other. There is no guard \
> in SharedOutputBuffer to ensure that `endStream` is called only once. Is this the \
> correct fix? I'm happy to submit a PR if this the right solution. Thank you!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]