Duplicate messages sent by transaction after EMS failover.
Article ID: KB0093642
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
When an EMS failover takes place, especially when the EMS primary server is terminated (e.g., kill -9 <ems_pid>), the application may receive a TransactionRolledBackException on messages that are already sent and committed in the primary server. If the application catches this exception and resends the message, the EMS server will receive duplicate messages. This is expected as stated in JMS specification, Section 6.2.12.
=======
6.2.12. Duplicate production of messages.
JMS providers must never produce duplicate messages. This means that a client that produces a message can rely on the JMS provider to ensure 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. It is up to the 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.
When an EMS failover takes place, especially when the EMS primary server is terminated (e.g., kill -9 <ems_pid>), the application may receive a TransactionRolledBackException on messages that are already sent and committed in the primary server. If the application catches this exception and resends the message, the EMS server will receive duplicate messages. This is expected as stated in JMS specification, Section 6.2.12.
=======
6.2.12. Duplicate production of messages.
JMS providers must never produce duplicate messages. This means that a client that produces a message can rely on the JMS provider to ensure 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. It is up to the 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.
In the situation where the commit has already succeeded on the server side, but disconnection occurs while the client is waiting for the commit confirmation from the EMS server, the "TransactionRolledBackException" exception will be thrown. If the application does not resend a message after receiving the exception, it should have at most the total number of messages, but possibly less. It is left to the application to resolve the ambiguity as stated in the specification. The application should determine if the transaction should be re-done and be able to accommodate duplicate messages. If the application is a BW application, contact Tibco Support for further assistance.
Issue/Introduction
Duplicate messages sent by transaction after EMS failover.
Additional Information
JMS specification.
Feedback
Yes
No
Powered by
