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.5In 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.
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.