1 Reply Latest reply on Jun 26, 2013 1:22 AM by RyanGardner

    coherence version mismatch


      Hi ,


      I have a scenario where I run a bunch of coherence jvms in a cluster.

      There is a slight mismatch in coherence version on the data nodes (3.5.3/465 p2) & that of the non-storage nodes (3.5.3/465).

      I intermittently see issues which prevents the managed node from joining the cluster, with the following error  -


      This member could not join the cluster because of an incompatibility between the cluster protocol used by this member and the one being used by the rest of the cluster.  This is most likely caused by a Coherence version mismatch, or by mismatched protocol filters (e.g. compression, or encryption). Rejected by Member(Id=1 ....


      All my nodes have the same config override file.

      Is it mandatory that the non-storage & storage nodes have the same minor version of coherence (in this case it seems like the difference is in build# right ? ).


      I am using unicast listener for WKA which explicitly points the data nodes in cluster.


      Any pointers/suggestions , highly appreciated.

        • 1. Re: coherence version mismatch

          I was told by coherence support that having things on different minor versions is "not really supported". They let you join them together to support a gradual rolling upgrade, but they really want them all on the same version.


          That being said I've never had that issue that you are talking about with things with the same minor version since the protocol versions don't change in minor versions.


          There is no source visibility so it is impossible to say what exactly changed between those versions - but it is unlikely that the protocol changed. (I'm not super familiar with the nuances of 3.5.3 - we were on Ye Olde Coherence 3.1 for far too long and then did a crazy jump straight to 3.7.1)