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.
>
|