[
https://issues.apache.org/jira/browse/QPID-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated QPID-3462:
-----------------------------------
Fix Version/s: (was: 0.15)
Future
> 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.10, 0.12
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Labels: failover
> Fix For: Future
>
>
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
