You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2012/09/12 23:35:07 UTC
[jira] [Commented] (QPID-3462) Failover is not transparent when
using CLIENT_ACK mode
[ https://issues.apache.org/jira/browse/QPID-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454376#comment-13454376 ]
Robbie Gemmell commented on QPID-3462:
--------------------------------------
Status of this JIRA is unclear, but significant changes were made to CLIENT_ACK handling last year, e.g https://issues.apache.org/jira/browse/QPID-3526
> 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: 0.15
>
>
> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org