qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-3462) Failover is not transparent when using CLIENT_ACK mode
Date Mon, 13 Feb 2012 23:17:00 GMT

     [ 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.14)
                   0.15
    
> 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
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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


Mime
View raw message