[
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: [email protected]
For additional commands, e-mail: [email protected]
