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.
