You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Malay Shah (Jira)" <ji...@apache.org> on 2020/07/21 01:01:02 UTC

[jira] [Updated] (HTTPCORE-638) SharedOutputBuffer calls endStream multiple times

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

Malay Shah updated HTTPCORE-638:
--------------------------------
    Description: 
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 with 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!

  was:
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 with 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!


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