activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: Reconciliation after ActiveMQ server crash.
Date Fri, 28 Nov 2008 16:21:01 GMT
This is handled by the ActiveMQ failover transport (the default in 5.1  
onwards).
It replays messages on your behalf that haven't been acknowledged -  
there is duplicate detection built in to the broker and the clients  
too ...

cheers,

Rob

cheers,

Rob

Rob Davies
http://fusesource.com
http://rajdavies.blogspot.com/


On 28 Nov 2008, at 13:09, thabach wrote:

>
> Hey everyone
>
> I have a conceptual question regarding reconciliation after a JMS  
> server
> crash. According to the JMS specification (paragraph 4.4.13, see  
> below)
> there is room for some ambiguity leaving a producer in doubt if a  
> message
> successfully made it to the server or not in case of server failure.
>
> The [X] part is what disquiets me: "It is up to a JMS application to  
> deal
> with this ambiguity."
>
> A producer in doubt can only resend the original message. In what  
> way does
> ActiveMQ support me in doing so ? Are there any means of having  
> ActiveMQ
> sort out potential duplicates sent by the application layers after  
> server
> recovery and publisher reconnect ? Or do downstream consumers have  
> to cope
> with these kind of duplicate messages somehow ?
>
> Regards and thanks for any insights, Christian.
>
>
> == JMS spec excerpt ============================================
>
> 4.4.13 Duplicate Production of Messages
> JMS providers must never produce duplicate messages. This means that a
> client that produces a message can rely on its JMS provider to  
> insure that
> consumers of the message will receive it only once. No client error  
> can
> cause a
> provider to duplicate a message.
>
> If a failure occurs between the time a client commits its work on a  
> Session
> and
> the commit method returns, the client cannot determine if the  
> transaction
> was
> committed or rolled back. The same ambiguity exists when a failure  
> occurs
> between the non-transactional send of a PERSISTENT message and the  
> return
> from the sending method.
>
> [X] It is up to a JMS application to deal with this ambiguity. In some
> cases, this
> may cause a client to produce functionally duplicate messages.
> A message that is redelivered due to session recovery is not  
> considered a
> duplicate message.
>
> ======================================================
>
> -- 
> View this message in context: http://www.nabble.com/Reconciliation-after-ActiveMQ-server-crash.-tp20734165p20734165.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>


Mime
View raw message