Configuring Clustered Servers

Last updated
Save as PDF

TeamConnect's clustering feature allows transparent failover and recovery for end users. In the event of a node's failure, each session on that node is transferred to another node, preserving even the uncommitted edits in the session's browser.

In the case of a recovered session, all work is saved except the uncommitted edits in the browser of the expired session.

Each application server vendor implements clustering and cache synchronization in a different way. This section does not discuss details of a specific vendor's implementation, but describes properties of TeamConnect that are common across all implementations.

Configure your application servers for session replication across all nodes. All nodes must run exactly the same version of TeamConnect.

Editing teamconnect.properties

The TeamConnect installer makes many changes to teamconnect.properties when it runs but to configure clustering you will need to make additional manual edits. Each node in a cluster runs an identical copy of TeamConnect, so the properties file needs to be edited only once per cluster.

Here are the properties that require editing, with their definitions:

Clustering Properties

Property Name	Definition	Suggested or Example Value
sync.enabled	A YES or NO value that determines whether TeamConnect attempts to do cache synchronization.	YES
sync.jms.topic.host	This refers to a configuration parameter in a Java Message Service (JMS) application, specifically indicating the hostname or IP address of the server that hosts a JMS topic for synchronous message communication.	tcp ://hostname:61616