Configuring Clustered Servers
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 |
|---|---|
|
sync.enabled |
Must be YES to enable clustering |
|
sync.channel |
Use a unique character string of your choice. The purpose of this property is to avoid the situation where multiple clusters of application servers are running on the same network, and one cluster attempts to synchronize cache with a different cluster Each cluster should have a different value in this property. |
|
sync.rmi.port |
Enter a port number that will be used by all nodes in the cluster. The RMI registry is started in-process by TeamConnect. |
|
sync.multicastGroupAdd ress |
Optional. Default is 226.10.12.64 |
|
sync.multicastPort |
Optional. Default is 3121 |
Special Considerations for IMAP
If you are using IMAP to integrate with an Exchange server, you must configure TCP/IP load balancing. IMAP does not use the failover or recovery capabilities of the main TeamConnect clustering feature.