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 WAS 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 existing messages or algorithm, a new protocol might not be able to interoperate with the old version of the protocol.
There are two major categories or groups of protocols.
- A collection of lower level protocols. The setting for the IBM_CS_WIRE_FORMAT_VERSION core group custom property determines which protocol version is used for this group of protocols.
A collection of higher level protocols. The setting for the IBM_CS_HAM_PROTOCOL_VERSION core group custom property determines which protocol version is used for this group of protocols.
The protocol version settings for each of these two categories are independent of each other.
Whenever a new protocol version is added to WAS ND:
- The new protocol version is assigned a unique ID.
- Support for the existing, in-service protocol versions is retained because all of the members of a core group might not be running at the same product level.
- The oldest supported protocol version is the default protocol version. Older protocol versions are deprecated using the standard product deprecation rules.
- You must explicitly update either the IBM_CS_WIRE_FORMAT_VERSION or the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to change the protocol version used with a core group.
Avoid trouble: We cannot update to a newer protocol version until all of the members of this core group are upgraded to a code level that supports the newer protocol version.
When to select a new core group protocol version
Core group protocol versions are always cumulative. Any functional enhancement that is provided in a previous protocol, is included in any subsequent protocols. IBM recommends that you always use the latest protocol version whenever possible. But, before configuring the members of a core group to use a new protocol version, make sure that all of the core group members are running at a WAS code level (VRM) that is equal to or greater than the new protocol version.
When we have determined that we can use a newer core group protocol level with a particular core group, use either the IBM_CS_WIRE_FORMAT_VERSION or the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to configure all of the core group members to run with that newer version. We can change the value of this property while the core group members continue to run. After you save and synchronize the changed value to all of the nodes containing core group processes, the high availability manager automatically detects the configuration change and starts using the new core group protocol version to communicate with the core group members.
Avoid trouble: You do not have to restart the core group members when you move from an older protocol version to a newer protocol version. However, restart all of the core group members if we move from a newer protocol version to an older protocol version.
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 WAS 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:
- JNDI lookups failing.
- A WebSphere proxy server, or on demand router generates a 503 response code after a core group bridge failover occurs
The following array index out-of-bounds exception occurs:
[7/9/08 17:12:20:749 EDT] 00000030 UserCallbacks E HMGR0142E: An error occurred in a component called back by the High Availability Manager The exception is java.lang.ArrayIndexOutOfBoundsException at com.ibm.ws.cluster.propagation.bulletinboard.BBDescriptionManager.getOrderedBytes(BBDescriptionManager.java:618)
Avoid trouble:
- If a core group is at a service level that does not support the 6.0.2.31 high availability manager protocol, that core group can still communicate with core groups that use the 6.0.2.31 high availability manager protocol. However, the core group is at a service level that does not support the 6.0.2.31 high availability manager protocol might still experience missing data during core group bridge failover.
- Transparent bridge failover is designed to hold state data constant during core group bridge rebuilds along the state data path, which is the path that consists of the state provider, one core group bridge in each respective core group, and a state data consumer. Failure scenarios involving core groups with no remaining active bridges might still result in temporary state outages.
Determining which protocol version to use
Best practice: IBM recommends that you always use the newest protocol version whenever possible. 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 WAS ND. For example:bprac
- A core group that only contains V7.0 core group members, or contains a mixture of V6.1.0.0 and 7.0 core group members can be configured to use either the V6.0.0, 6.0.2.9, or 6.1.0 wire format protocol.
- A core group that contains a mix of V6.1.0.19 and 7.0.0.1 core group members can be configured to use the V6.0.2.31 high availability manager protocol.
Supported core group protocol version IDs
The following tables summarize for each protocol category the minimum level of WAS 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 that is supported by the level of WAS 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 you 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 | 6.0.2.9 for V6.0.2, 6.1.0.0 for V6.1, 7.0.0.0 for V7.0. | This protocol version was included in the 6.0.2.9 service pack, and in Vs 6.1, and 7.0 of WAS to facilitate 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 | 6.1.0.0 for V6.1, 7.0.0.0 for V7.0 | This protocol version was included in Vs 6.1, and 7.0 of WAS ND. 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.0.2.31 for V6.0.2, 6.1.0.19 for V6.1, 7.0.0.1 for V7.0 | This protocol version is the original or base version of the high availability manager protocol, and is available in the 6.0.2.31, 6.1.0.19, and 7.0.0.1 and higher versions of WAS 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. |
Related concepts
Core groups (high availability domains)
Related tasks
Select the version of a core group protocol