Core Group Coordinator Revisited

In a previous article I mentioned the importance of having enough resources for your Core Group Coordinator to allow a properly functioning High Availability Manager. I also mentioned two custom properties for the DefaultCoreGroup:


Information on the protocol versions can be found in this link together with the requirements for setting above versions (minimum WebSphere 7.x which is met when installing any supported version of IBM Connections). IBM also mentions that setting the IBM_CS_HAME_PROTOCOL_VERSION has little use in an environment with a single core group or in their own words:

Although you can set the IBM_CS_HAM_PROTOCOL_VERSION custom property value in a topology in which only a single core group exists, it does not provide any benefit. However, if you need to later partition a cell into multiple core groups and bridge them together, it is better to have the core groups running the most current possible protocol version before you start the bridges. If your topology contains multiple core groups that are bridged together, set this value to the most current possible version. For the applicable values and information on how to set this custom property, see the IBM_CS_HAM_PROTOCOL_VERSION custom property description.

Others however have seen benefits from setting it even in a single core group environment and as it doesn’t hurt to set it, I would still use it in my Connections environments.

There’s another relevant setting though, which I didn’t mention in my original article as I didn’t think it was related to the Core Group Coordinator. It was later explained to me by Patrick Spielmann that it is related. This setting is:

This setting should improve the startup time of the environment. This setting needs to be set as a custom property to every single JVM. As that’s a bit of a pain, I’ll include a script to do this automatically, which was written by a former colleague of mine: Tom Bosmans: setDisableNonHARegistration