Qpid Proton
  1. Qpid Proton
  2. PROTON-323

Regression: Messenger sends "null" in disposition state after accept

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Not A Problem
    • Affects Version/s: None
    • Fix Version/s: 0.6
    • Component/s: proton-c
    • Labels:
      None

      Description

      Using the following Python code snippet:

      from proton import *
      mng = Messenger()
      mng.start()
      mng.subscribe("amqp://0.0.0.0/Queue_1")
      mng.timeout=100
      mng.recv()
      msg = Message()
      t = mng.get(msg)
      mng.accept(t)
      mng.stop()

      The following trace is seen after the call to stop:

      [0xf7f6a0:1] -> DISPOSITION @21 [true, 0, 0, true, null]

      On Proton 0.4, this problem does not exist. The trace is:

      [0x1087bb0:1] -> DISPOSITION @21 [true, 0, 0, true, @36 []]

        Activity

        Hide
        Ted Ross added a comment -

        This test was run against ActiveMQ 5.8. It was observed that received and accepted messages were not removed from the queue on the broker. This is apparently due to the missing state in the disposition frame.

        Show
        Ted Ross added a comment - This test was run against ActiveMQ 5.8. It was observed that received and accepted messages were not removed from the queue on the broker. This is apparently due to the missing state in the disposition frame.
        Hide
        Rafael H. Schloming added a comment -

        The 0.5 behaviour is actually correct. The reason the disposition is null is because the incoming window is zero and so the delivery is settled as soon as get is called. The accept() in this code snippet is actually a noop because the message has already fallen off the zero sized window. If you add the line "mng.incoming_window = 1" to the code snippet, then it behaves similarly to 0.4, e.g.:

        [0x251fe20:0] -> @disposition(21) [role=true, first=0, last=0, settled=false, state=@accepted(36) []]

        Note the state=@accepted(36) above.

        Show
        Rafael H. Schloming added a comment - The 0.5 behaviour is actually correct. The reason the disposition is null is because the incoming window is zero and so the delivery is settled as soon as get is called. The accept() in this code snippet is actually a noop because the message has already fallen off the zero sized window. If you add the line "mng.incoming_window = 1" to the code snippet, then it behaves similarly to 0.4, e.g.: [0x251fe20:0] -> @disposition(21) [role=true, first=0, last=0, settled=false, state=@accepted(36) []] Note the state=@accepted(36) above.

          People

          • Assignee:
            Rafael H. Schloming
            Reporter:
            Ted Ross
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development