[ http://jira.jboss.com/jira/browse/JBAS-1476?page=comments#action_12315480 ] Ole Husgaard commented on JBAS-1476: ------------------------------------
Bela Ban commented: // Since the timestamp uses wall clock time, a client might get a superfluous topology change on a response, but this would only happen when failing over to a different server, and the servers times are not sync'ed Please note that with a round robin loadsharing policy the node accessed changes constantly. Please also note the even though server times are in sync, the tick to the next millisecond can happen a few microseconds before on one of the servers. I think that Adrians notion of a cluster GUID is better. This could be a combination of a server IP address and a timestamp. The only potential problem I see with Adrians suggestion is when two clusters that started out as seperate clusters with different cluster GUIDs because they could not communicate end up merging. But that is really a border case, worse than a cluster split. > Need to include a notion of cluster instance in the cluster view > ---------------------------------------------------------------- > > Key: JBAS-1476 > URL: http://jira.jboss.com/jira/browse/JBAS-1476 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Priority: Critical > > > We need to include a notion of cluster instance in the cluster view id > to avoid at least the following scenario: > Client serializes a handle to a cluster which is at cluster view 22 > Handle contains key DefaultPartition/HAJNDI/22 > The cluster is totally restarted meaning the view reverts back to one. > The client now has a view id > DefaultPartition/HAJNDI/1 > The client deserializes the handle, which will overwrite the correct cluster > view with the old invalid view. > ---- > This will also avoid the problem where a client talks to different clusters > with the same partition name. > ---- > Proposed solution: > 1) At cluster formation (first node in cluster), create a cluster instance > GUID > 2) At cluster join (second+ node in cluster) get the GUID from the coordinator > 3) Include this GUID in cluster view keys, i.e. > GUID/DefaultPartition/HAJNDI/1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
