Qpid
  1. Qpid
  2. QPID-4595

Invoking Receiver::fetch() in a loop for slow producer causes only first <prefetch> messages received

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.18
    • Fix Version/s: 0.21
    • Component/s: C++ Client
    • Labels:

      Description

      Description of problem:
      Having a scenario with a slow producer and a consumer periodically running Receiver::fetch() method (for timeout lesser than forever), the consumer gets just first N messages where N is the size of prefetch / capacity, and then nothing - despite there are new messages on the broker.

      Version-Release number of selected component (if applicable):
      qpid-cpp-client*-0.18-14

      How reproducible:
      100%

      Steps to Reproduce:
      1. Unpack attached tarball
      2. make
      3. in one terminal, create queue and start producer (that waits 15 seconds to kick-off consumer first):
      ./setup
      4. in another terminal, start consumer:
      ./read

      Actual results:
      When producer starts to produce messages, the consumer gets just first 10 messages (or whatever is set in receiver.setCapacity()). Later on, despite there are new messages in the queue, receiver does not get any.

      Expected results:
      Receiver gets further messages when some occurr on the broker.

      Additional info:
      Patch proposed

      1. bz913448.patch
        2 kB
        Pavel Moravec
      2. bz913448_reproducer.tar.gz
        2 kB
        Pavel Moravec

        Activity

        Pavel Moravec created issue -
        Hide
        Pavel Moravec added a comment -

        Reproducer

        Show
        Pavel Moravec added a comment - Reproducer
        Pavel Moravec made changes -
        Field Original Value New Value
        Attachment bz913448_reproducer.tar.gz [ 12570446 ]
        Hide
        Pavel Moravec added a comment -

        Patch proposal.

        Root cause of the bug: see qpid::client::amqp0_10::ReceiverImpl::fetchImpl method:

        After sending message.flush, the consumer's credit is zero so it re-sets it by calling startFlow(ScopedLock) method. BUT session.complete command is not sent to really update the credit.

        Invoking that requires received(message); method call. To perform the call properly, startFlow can't update window - thats why startFlow has a new bool parameter.

        Show
        Pavel Moravec added a comment - Patch proposal. Root cause of the bug: see qpid::client::amqp0_10::ReceiverImpl::fetchImpl method: After sending message.flush, the consumer's credit is zero so it re-sets it by calling startFlow(ScopedLock) method. BUT session.complete command is not sent to really update the credit. Invoking that requires received(message); method call. To perform the call properly, startFlow can't update window - thats why startFlow has a new bool parameter.
        Pavel Moravec made changes -
        Attachment bz913448.patch [ 12570447 ]
        Gordon Sim made changes -
        Assignee Gordon Sim [ gsim ]
        Hide
        Gordon Sim added a comment -

        Fixed by http://svn.apache.org/viewvc?view=revision&revision=1455630. This is not exactly the same as the suggested patch, but simply ensures any completions are sent to the broker on a flush. Thanks for raising the issue and identifying the fix Pavel!

        Show
        Gordon Sim added a comment - Fixed by http://svn.apache.org/viewvc?view=revision&revision=1455630 . This is not exactly the same as the suggested patch, but simply ensures any completions are sent to the broker on a flush. Thanks for raising the issue and identifying the fix Pavel!
        Gordon Sim made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 0.21 [ 12323549 ]
        Resolution Fixed [ 1 ]
        Justin Ross made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        18d 8h 53m 1 Gordon Sim 12/Mar/13 17:17
        Resolved Resolved Closed Closed
        139d 1h 36m 1 Justin Ross 29/Jul/13 19:53

          People

          • Assignee:
            Gordon Sim
            Reporter:
            Pavel Moravec
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4h
              4h
              Remaining:
              Remaining Estimate - 4h
              4h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development