+

Search Tips   |   Advanced Search

Core group protocol versions

Core group members interact with each other through a variety of protocols such as the discovery protocol, the failure detection protocol, and the view synchrony protocol. Each of these protocols define a set of formatted messages that core group members exchange according to a common algorithm.

New protocol versions are added to the product if new messages, or new algorithms are required to support new product features, or to improve core group performance. Because the new messages or new algorithm might not be compatible with the older messages or algorithm, a new protocol might not be able to interoperate with the previous version of the protocol.

The highest protocol versions are used by default instead of older versions as specified by previous WebSphere releases. The following custom properties can be used to revert back to older protocol versions; however, this is not recommended.

Mixed-version environment: To maintain compatibility in a mixed cell environment, the custom properties below will need to be explicitly set to use the highest protocol levels.mixv

There are two major categories or groups of protocols.

The protocol version settings for each of these two categories are independent of each other.


When to use an older core group protocol version

It is not recommended to use an older core group protocol version. The only time when this is needed is in a Core group containing a mix of v9 servers and servers on v7.0.0.0 or lower.


Use the high availability manager protocol to establish transparent bridge failover support

Core group bridges provide the mechanism used to represent and manage the cross core group state used by WebSphere Application Server components. Part of the management process for this cross-core group state is to perform core group bridge state rebuilds whenever there is a change in the number of running core group bridges in a topology. The core group bridge state rebuild is the means by which core group bridges calculate the ownership, and distribution of the cross-core group state among the running set of bridges.

During core group bridge state rebuilds, cross-core group state can be moved between running bridges. This situation might cause the data to be temporarily unavailable until the bridge has completed the rebuild process. Common symptoms of this problem include:

If we are running on v7.0.0.1 to v8.5.5.X, set the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to 6.0.2.31 for all of our core groups to avoid a possible high availability state outage during core group bridge failover. When this custom property is set to 6.0.2.31, the remaining bridges recover the high availability state of the failed bridge without the data being unavailable in the local core group.bprac


Determining which protocol version to use

Use the newest protocol version whenever possible (this is the default in v9). This practice is especially critical for large topologies because most of the recent protocol changes include scalability improvements. However, before configuring the members of a core group to use a new protocol version, verify that all of the core group members are running at a product code level (VRM) that is equal to or greater than the VRM in which the desired protocol version was added to the product. For example:bprac


Supported core group protocol version IDs

The following tables summarize for each protocol category the minimum level of the product that core group members must be running at before they can be associated with a specific protocol version. These tables also describe the new capabilities that were added in each protocol version.

Use these tables to determine which protocol versions we can use with a particular core group, and then use either the IBM_CS_WIRE_FORMAT_VERSION or the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to configure all of the members of that core group to run using the newest of those protocol versions supported by the level of the product on which we are running. The high availability manager automatically detects the configuration changes and starts to use the new core group protocol version with these core group members.

Deprecated feature: Wire format protocol versions 6.0.0 and 6.0.2.9 are deprecated. Whenever possible we should use a newer protocol version.depfeat

Version ID Required Minimum product Level Description
6.0.0 Any This protocol version is the original or base version. All versions of the high availability manager can use this protocol. If we do not specify a particular wire format protocol version, the high availability manager uses this version.
6.0.2.9 Any supported version This protocol version facilitates core group bridge scalability. This version is recommended for large topologies that contain multiple core groups and core group bridges as part of their configuration.
6.1.0 Any supported version This version adds core group scalability improvements, and more support for large topologies.

Version ID Required Minimum product Level Description
6.0.2.31 6.1.0.19 for v6.1, 7.0.0.1 for v7.0, and the initial release of any later versions of the product This protocol version is the original or base version of the high availability manager protocol, and is available in any supported version of the product to facilitate core group bridge scalability. This protocol version is recommended for topologies that contain multiple core groups and core group bridges as part of their configuration. Specify the high availability manager protocol version for the high availability manager to use the protocol. There is no default version.

IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure . We view HPEL log and trace information using the logViewer .

  • Select the version of a core group protocol