qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu (JIRA)" <j...@apache.org>
Subject [jira] [Created] (QPID-3462) Failover is not transparent when using CLIENT_ACK mode
Date Fri, 02 Sep 2011 02:23:09 GMT
Failover is not transparent when using CLIENT_ACK mode

                 Key: QPID-3462
                 URL: https://issues.apache.org/jira/browse/QPID-3462
             Project: Qpid
          Issue Type: Bug
          Components: Java Client
    Affects Versions: 0.12, 0.10
            Reporter: Rajith Attapattu
            Assignee: Rajith Attapattu
             Fix For: 0.14

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?



This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message