Wasn't clear in last post.
Passing a cluster instance id between client and server as a separate value allows the client to avoid the JBAS-1476 problem of having its FamilyClusterInfo target set overwritten by a bad proxy left over from a previous cluster instance. But on the forum thread we decided a discovery mechanism is a more generally useful solution to that issue.
Incorporating the cluster instance id in the viewId hash would enable avoidance of any issue of the type discussed in this post: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3936124#3936124. As the post says, though, the issue is not significant.
Basically I'm raising the idea of adding a cluster instance id to JGroups mostly because it seems like a reasonable construct to have, and 2.3 might be a good opportunity to introduce it.
I will introduce logical addresses to JGroups in 2.4 (http://jira.jboss.com/jira/browse/JGRP-129). So each View's ViewId will have an ID (creator) which is unique across space (custer) and time. This will use a VMID or GUID, or something equivalent.
I don't want to add anything to JGroups 2.3 which will further delay 2.3, and will need proper reimplementation in the more generic concept of addresses in 2.4 anyway
Perfect. Didn't know about the creator ID part of JGRP-129. 2.3 vs 2.4 doesn't matter to me, as 2.4 should go in 5.0.