Fault Tolerance
Multiple adapter configurations can substitute for each other with Fault Tolerance. When the primary adapter configuration ends unexpectedly, the token held by the primary adapter configuration can be taken over by an adapter configuration in the standby state. In the process of replacement, the standby adapter configuration is promoted to the primary adapter configuration.
Fault Tolerance is based on the JMS queue. Before enabling Fault Tolerance, you have to define a JMS queue, set the prefetch parameter of the JMS queue to none, and then put several JMS messages in the JMS queue as tokens. The number of tokens corresponds to the number of primary adapter configurations.
- When a standby adapter configuration becomes a primary adapter configuration, it does not take the instance ID of the original primary adapter configuration that ended unexpectedly and still has its own instance ID.
- When running JMS topic as durable, durable names exist on the EMS server for each receiver, regardless of whether adapter configuration is primary or standby.
- To detect broken connections more quickly, you can add the client_heartbeat_server=3 property to the tibemsd.conf files of all the primary servers and standby servers.
The following diagram shows how Fault Tolerance works. At first, adapter configuration 1 and 2 fetch one of the two tokens in the JMS queue respectively. They hold the tokens and process messages as primary adapter configurations. Adapter configuration 3 does not fetch tokens and runs in standby state. If adapter configuration 2 ends unexpectedly, it releases the fetched token. Adapter configuration 3 fetches the token released by adapter configuration 2 and continues to process messages as primary adapter configuration.