When a backup server (B) detects the failure of the primary server (A), then B attempts to assume the role of primary server. First, B obtains the lock on the current shared state. When B can access this information, it becomes the new primary server.
If B cannot obtain the lock immediately, it alternates between attempting to obtain the lock (and become the primary server), and attempting to reconnect to A (and resume as a backup
server)—until one of these attempts succeeds.
Clients of A that are configured to failover to backup server B automatically transfer to B when it becomes the new primary server. B reads the client’s current state from the shared storage to deliver any persistent messages to the client.
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.
A transaction is considered active when at least one message has been sent or received by the session, and the transaction has not been successfully committed.
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 backup server automatically redelivers any messages that were delivered to the session during the transaction that rolled back.
For queue receivers, any messages that have been sent to receivers, but have not been acknowledged before the failover, may be sent to other receivers immediately after the failover.
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.
When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server.
The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. You can set these intervals in the server configuration files. See
Fault Tolerance Parameters for details.