To receive notification, Java client programs set the system property tibco.tibjms.ft.switch.exception to any value, and define an
ExceptionListener to handle failover notification; see the class
com.tibco.tibjms.Tibjms in
TIBCO Enterprise Message Service Java API Reference.
To receive notification, C client programs call tibems_setExceptionOnFTSwitch(TIBEMS_TRUE) and register the exception callback in order to receive the notification that the reconnection was successful.
To receive notification, .NET client programs call Tibems.SetExceptionOnFTSwitch(true), and define an exception listener to handle failover notification; see the method
Tibems.SetExceptionOnFTSwitch in
TIBCO Enterprise Message Service .NET API Reference.
When a failure occurs, messages with delivery mode PERSISTENT, that were not successfully acknowledged before the failure, are redelivered.
When using durable subscribers, EMS guarantees that a message with PERSISTENT delivery mode and written to a
store with the property
mode=sync, will not be lost during a failure.
After a failover, attempting to commit the active transaction results in a javax.jms.TransactionRolledBackException. Clients that use transactions must handle this exception, and resend any messages sent during the transaction. The standby server, upon becoming active, automatically redelivers any messages that were delivered to the session during the transaction that rolled back.
A receiver trying to acknowledge a message after a failover may receive the javax.jms.IllegalStateException. This exception signifies that the attempted acknowledgement is for a message that has already been sent to another queue receiver. This exception only occurs in this scenario, or when the session or connection have been closed. This exception cannot occur if there is only one receiver at the time of a failover, but it may occur for exclusive queues if more than one receiver was started for that queue.
When a queue receiver catches a javax.jms.IllegalStateException, the best course of action is to call the
Session.recover() method. Your application program should also be prepared to handle redelivery of messages in this situation. All queue messages that can be redelivered to another queue receiver after a failover always have the header field
JMSRedelivered set to
true; application programs must check this header to avoid duplicate processing of the same message in the case of redelivery.