Integration Server 10.3 | Clustering Guide | Managing Server Clustering | How a Stateful Integration Server Cluster and a Terracotta Server Array Handle Failures | What Happens When Integration Server in a Stateful Cluster Is Disconnected from the Terracotta Server Array?
 
What Happens When Integration Server in a Stateful Cluster Is Disconnected from the Terracotta Server Array?
When an Integration Server in a stateful cluster is disconnected from the Terracotta Server Array, the following occurs:
*Integration Server will accept new connections.
*Stateless sessions, new and existing, will continue to be fully functional. Note that stateless session information is not written to Terracotta Server Array.
*Stateful sessions, new and existing, will execute but will limited functionality because stateless session information will not be replicated to other Integration Servers in the cluster as long as the Integration Server remains disconnected from the Terracotta Server Array. The Integration Server maintains its own session state information and does not have access to state information from other cluster members while disconnected from the Terracotta Server Array.
When executing a top-level stateful service, Integration Server attempts to write to the Terracotta Server Array after service invocation completes. If the Timeout Behavior is set to localReads or exception, the attempt to write to the Terracotta Server Array returns an exception. Integration Server writes this exception, often a NonStopCacheException, to the server log as part of the following error message: [ISS.0033.0154E] Could not save session sessionID to the session cache. exceptionMessage
At the time Integration Server reconnects to the Terracotta Server Array, session state information becomes available across the cluster. However, all of the Integration Servers in the cluster might have different session state information. The first Integration Server to process a request updates the Terracotta Server Array with the new session state information. The updated session information becomes the session state for all of the Integration Servers in the cluster going forward. When another Integration Server begins to process a request for the session, that Integration Server retrieves the session state from the Terracotta Server Array. Consequently, session information on other Integration Servers in the cluster might be lost.
*How distributed caches in Integration Server behave during a loss of connection is controlled by the Timeout, Immediate Timeout When Disconnected, and Timeout Behavior settings for each distributed cache. For information about these settings, see Configuring a Distributed Cache.
Clients for a distributed cache continue to process requests, if all of the following are true:
*The Timeout Behavior parameter for each distributed cache is set to localReads or noop.
*The services do not attempt to write any data to a distributed cache for which the Timeout Behavior is localReads or exception.
*The list of cluster hosts on the Settings > Cluster page will not contain any cluster members.
*The Integration Server writes entries to the tc-client-logs and ehcache log files when it disconnects and reconnects to the Terracotta Server Array.
The way in which Integration Server rejoins the Terracotta Server Array depends on how long the connection is lost.
If...
Then...
The connection is momentarily interrupted
If the Terracotta Server Array is configured to automatically reconnect, the Integration Server identity and state are retained on the Terracotta Server Array so that Integration Server can readily reconnect when the connection is restored. To learn more about the reconnect behavior of a Terracotta Server Array, see the information about automatic client reconnect in the Configuring Terracotta Clusters For High Availability documentation on the Terracotta website.
If the Terracotta Server Array is not configured to automatically reconnect, the Integration Server will attempt to rejoin the Terracotta Server Array.
The connection is lost for a long period of time
Integration Server attempts to rejoin the Terracotta Server Array. To prevent inconsistencies in your distributed cache, Terracotta automatically acquires a new cache state from the Terracotta server after rejoining the Terracotta Server Array. For more information about the rejoin and nonstop behavior of Integration Server, see The Rejoin Behavior of a Distributed Cache..