Adding a GUID to JGroups Views

[brian.stansberry]

Wanted to float the idea of adding a "cluster instance id" to JGroups views.

This relates to http://jira.jboss.com/jira/browse/JBAS-1476
and the related discussion at
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73652 . In that thread, we've determined that adding a discovery mechanism to client proxies is a more robust solution than including a cluster instance id.

However, I still think having the ability to identify a cluster instance has merit and could be useful. If breaking serializable compatibility is allowable in JG 2.3, this might be a good time to introduce such a thing in JG.

A simple approach would be to create a java.rmi.dgc.VMID when a ClientGmsImpl converts to a CoordGmsImpl. Thereafter, that VMID is passed around as part of the view no matter who the coordinator is.

Related to the JBAS-1476 discussion, the current viewId passed back and forth between clustering clients and the server is a hash of JGroups IpAddresses. If we had a cluster instance id, we could include that in the hash function. Not necessarily any need to propagate it separately, meaning no API changes needed.

[brian.stansberry]

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.

[belaban]

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

[brian.stansberry]

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.