Horizontal Scalability Behavior in a Mixed Landscape
Because a higher-release Java client can connect to a lower-release server, in mixed server environments, the client might use a different release version for each server. Different versions can cause inconsistent behavior when operating against a horizontal scalability (HS) landscape. For example, some operations that are unsupported for some servers might not function properly.
In such cases, you must modify the HS URL of your application, restricting it to use the lowest server release version available within the HS landscape. To identify the lowest release version, you run the ServerReleaseVersion command-line administration tool. The tool returns an HS URL that contains the hsReleaseVersion parameter.
For more information about using the
ServerReleaseVersion tool, see
The ServerReleaseVersion Tool.
The hsReleaseVersion parameter is an optional HS URL parameter that configures the Universal Messaging connection protocol release version to use when the client connects to an HS group of servers. The value of the parameter has a major.minor format, where the major and minor version components must be positive integers representing a valid Universal Messaging release version.
For example, you can have the following HS URL including hsReleaseVersion:
(nsp://localhost:9000)(nsp://localhost:9001)?hsReleaseVersion=10.5
In this example, the client will try to connect to both Universal Messaging servers requesting a connection protocol version of 10.5. If any of the servers does not support the configured version, connectivity to this server will not be established and it will not be available for user operations. However, while the horizontal scalability session is active, the session will continue to retry to connect to the target server in the background.
Important:
If you do not specify hsReleaseVersion in the HS URL, the session will validate that all servers have matching release versions (up to major and minor version components) and will fail to initialize if the versions of any of the servers are different. If some of the servers are not online during session initialization, but become available later after the session is initialized, and negotiate a different Universal Messaging connection protocol version than the rest of the servers, the client will log an error message and close the session automatically.
For more information about bi-directional client and server compatibility, see
Bi-directional Client and Server Compatibility.