Operational Layer Components

Load Balancing Core Engines

All the instances of the Core Engine automatically behave in a fault tolerant manner. The load balancer distributes the load of requests within all active agents in the same group as per the configuration setup described in Configure Load Balancer section. If any Core Engine instance fail, the load balancer distributes the load between the remaining active Core Engine instances in the group.

There is no discovery protocol between Apache server and the Core Engine. If one of the Core Engine instance goes down, the Apache server is not able to determine that this instance is not available and keeps sending the requests to the Core Engine which results in all those requests timing out. For this reason, it is good practice that you do not use a single Apache server to send request messages to multiple instances of the Core Engines.

For the Apache server and Core Engine configuration setup, you must consider:

• There should be a single Apache server per Core Engine instance. For example, if you plan to run two instances of Core Engine instances, you must setup two Apache servers, one Apache server for each Core Engine instance.
• You must configure health monitor of the load balancer to call the gateway ping operation so that the load balancer can determine which instances of the Core Engines are up and running. See Configure Load Balancer for configuration details. If any of the Apache server or the Core Engine instance goes down, the load balancer considers it as a failure to forward the request and routes the request to the second active instance of Apache server as configured in the load balancer group.

Cache Agents

TIBCO API Exchange Gateway supports in memory caching of the data. Fault tolerance of Cache Agents is handled transparently by the object management layer. For fault tolerance of cache data, the only configuration task is to define the number of backups you want to keep. Use of a backing store is not needed as the Cache Agents are only used to implement the association cache, which is automatically rebuilt after complete failure as new transactions are handled by the API Exchange Gateway.