Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 Fault Tolerance and Load Balancing in a Rendezvous Administration Domain : Load-Balanced Servers

Load-Balanced Servers
If you wish to use multiple load-balanced servers, you must install TIBCO Administrator once for each server. You must designate one server as the primary, and all other servers as secondary servers.
For the simplest case, you can just install multiple servers and designate them as a primary or secondary server using the TIBCO Domain Utility, which is launched at the end of installation and can also be invoked separately afterwards. In some cases you also edit properties in the tibcoadmin_domain.tra file for each administration server in the domain and restart each server.
Optionally, if you set up multiple servers to talk to each other across a WAN, you can use a subject prefix to specify a preference for local servers for clients communicating using TIBCO Rendezvous. The subject prefix is specified in the server’s property file in the repo.prefixRegionalSubject property as explained later in this section.
The following properties affect load balancing. The properties are set in the administration server’s configuration file, tibcoadmin_domain-name.tra.
The repo.master property distinguishes the primary server from the secondary servers. If the value is set to a hostname or default IP address, it is a primary server. Any other value indicates a secondary server. For example, the bogus value 255.255.255.255 indicates a secondary server.
As a side effect of enabling fault tolerance, a small _RVFT message is sent once a second. If you do not intend to run in fault tolerant mode, that is, you wish to use only a primary server and no secondary servers, you can disable fault tolerance by commenting out the repo.master property in the configuration (.tra) file. In that case, the _RVFT message is no longer sent.
If you comment out the repo.master property, you cannot add secondary servers until you have manually removed the comment.
If the repo.isMaster property is set true, it overrides the repo.master property to allow the primary server to be specified in a cluster environment.
The repo.state property defaults to READ_WRITE if the repo_master property is set. You can set this property to READ_ONLY explicitly to have a server come up in that state upon startup. The primary server and all secondary servers should have the same value set. This value indicates the global state for the set of servers.
By default, the global state is READ_WRITE. This allows the primary server to handle both read and write requests, while the secondary servers only handle read requests. Some sites wish to limit updates to specific windows of time. The following states are supported:
READ_ONLY—If the primary has been set to READ_ONLY, and the client application tries to perform an operation that involves locking or writing to the application or domain repository, a SERVER_STATE_READ_ONLY exception results.
READ_WRITE—The primary server’s state must be READ_WRITE if you wish to make changes to projects. Only the primary server can handle write request, but all secondary servers will continue serving read requests.
The repo.prefixRegionalSubject property specifies a prefix for the TIBCO Rendezvous subject. In load balancing mode, servers with that prefix are considered preferred servers for read operations.
This string is used for giving preference to a group of load balancing servers over the rest of load balancing servers. Each repository client and server which participates in load-balancing may have optional regional information. If this optional property is set, servers in load-balancing mode listen on the extra read subject that incorporates this region. If an optional regional subject is set for a client, the client directs read operations to that subject first. If no server is available, then the client retries using the regular (non-prefixed) read subject.
You must set this property explicitly in the tibcoadmin_domain.tra file and for each repository locator string used in client .tra files.
The repo.updateSecondaryServerPersistentStore property only applies to secondary servers. It determines whether or not secondary servers working in load balancing mode write data into their persistent backend. If the backend is shared by the primary server and this secondary server, this property should be set to false. If this property is set to true, the secondary server will update not only its cache but also its backend whenever it synchronizes a change with the primary server. Currently this property cannot be set to true for secondary servers that use a database backend. Default value for this property is true.
You must set this property explicitly in the tibcoadmin_domain.tra file.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved