This section presents details of the failover sequence.
A backup server detects a failure of the primary in either of two ways:
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.
When B becomes the new primary server, A can restart as a backup server, so that the two servers exchange roles.
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.
Client applications can receive notification when failover occurs.
![]() |
To receive notification, Java client programs can 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, .NET client programs can 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.
|
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.
When a failure occurs, messages with delivery mode PERSISTENT
, that were not successfully acknowledged before the failure, are redelivered.
EMS guarantees that a message with PERSISTENT
delivery mode and a failsafe destination will not be lost during a failure.
Any messages that have been successfully acknowledged or committed are not redelivered, in compliance with the JMS 1.1 specification.
All topic subscribers continue normal operation after a failover.
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.
![]() |
Acknowledged messages are never redelivered (in compliance with the JMS specification). The case described above occurs when the application cannot acknowledge a message because of a failover.
|
A transactions 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.
When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then 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 using the administration tool or in the server configuration files.
For more information about these parameters, see Fault Tolerance Parameters.
TIBCO Enterprise Message Service™ User’s Guide Software Release 4.3, February 2006 Copyright © TIBCO Software Inc. All rights reserved www.tibco.com |