Qpid
  1. Qpid
  2. QPID-3462

Failover is not transparent when using CLIENT_ACK mode

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.10, 0.12
    • Fix Version/s: Future
    • Component/s: Java Client
    • Labels:

      Description

      If a session is using CLIENT_ACK mode fails over to another broker, and calls acknowledge on a message it received before failover, the client throws an IllegalStateException.

      The JMS spec states, that the IllegalStateException should only be thrown if the session is closed. When failover happens the JMS session (or the JMS Connection) is not closed, instead we transparently reconnect and create a new AMQP session and allow the application to continue as nothing happens. Therefore throwing the above exception is incorrect.

      We have three options for handling this case.

      1. Throw a JMSException notifying the application that this message was received in the previous session. This notifies the application that the acknowledge didn't succeed and the message is going to be redelivered.

      2. Not throw an exception at all. The application is anyhow prepared to handle duplicates, so this would not be an issue at all. With JMS the last acked message is always in doubt. If the application is using CLIENT_ACK and acknowledging after 'n' messages, then it should be prepared to handle 'n' duplicates in the event of a failover.

      2. The client library can make it totally transparent by not throwing an exception at all.
      Instead it can look up this messages (along with all the other unacked messages upto that point) in it's dispatch queue received after failover. The messages can be identified using the message ID (and they will also be marked re-delivered by the broker).

      It can then call acknowledge on these messages and remove them from the dispatch queue. i.e they will not be redelivered to the application at all.

      What do you think is the best option?

      Regards,

      Rajith

        Activity

          People

          • Assignee:
            Rajith Attapattu
            Reporter:
            Rajith Attapattu
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development