Uploaded image for project: 'HttpComponents HttpCore'
  1. HttpComponents HttpCore
  2. HTTPCORE-638

SharedOutputBuffer calls endStream multiple times

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 5.0.2
    • Component/s: HttpCore NIO
    • Labels:
      None

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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mns Malay Shah
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 40m
                40m