Skip to main content
Mitratech Success Center
Client Support Center

Need help? Click a product group below to select your application and get access to knowledge articles, webinars, training content, and release notes or to contact our support team.

Authorized users - log in to create a ticket, view tickets status and check your success plan details.

 

Configuring Clustered Servers

  1. Last updated
  2. 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
sync.jms.initial.jms.timeout.constant Specifies whether the initial JMS synchronization timeout uses a fixed or adaptive wait. Set to YES to use a fixed wait or NO to use an adaptive wait. The default value is YES.
Important: If set to YES, sync.jms.expected.cluster.sizeshould also be populated to avoid unnecessary waits.		 YES
sync.jms.expected.cluster.size Specifies the expected number of nodes in the TeamConnect cluster. Set this value to the exact number of nodes in the cluster.

For example, specify 2 for a two-node cluster or 5 for a five-node cluster. This property should be populated when sync.jms.initial.jms.timeout.constant is set to YES.		 Numeric value (Number of node in the cluster)
  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Topic
  2. Tags
    This page has no tags.