Qpid
  1. Qpid
  2. QPID-4302

0-8..0-9-1 client should sync after message.acknowledge()

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18
    • Fix Version/s: 0.19
    • Component/s: Java Broker
    • Labels:
      None

      Description

      In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again.

      Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully.

      The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands.

      For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired.

        Issue Links

          Activity

          Robbie Gemmell made changes -
          Resolution Fixed [ 1 ]
          Status Ready To Review [ 10006 ] Resolved [ 5 ]
          Keith Wall made changes -
          Assignee Keith Wall [ k-wall ] Robbie Gemmell [ gemmellr ]
          Keith Wall made changes -
          Status In Progress [ 3 ] Ready To Review [ 10006 ]
          Keith Wall made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Keith Wall made changes -
          Summary make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously 0-8..0-9-1 client should sync after message.acknowledge()
          Description For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again.

          Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully.

          The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands.







          For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired.
          Keith Wall made changes -
          Summary make sure the 0-8..0-9-1 client message.acknowledge() actually acknowledges messages immediately, and does so synchronously make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously
          Description For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediatelly in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired.
          Keith Wall made changes -
          Field Original Value New Value
          Link This issue relates to QPID-3526 [ QPID-3526 ]
          Keith Wall created issue -

            People

            • Assignee:
              Robbie Gemmell
              Reporter:
              Keith Wall
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development