[ http://jira.jboss.com/jira/browse/JGRP-31?page=comments#action_12315541 ] B.S.Navin commented on JGRP-31: -------------------------------
Using a temp persistence store may not solve the issue. The issue would crop up if the network issue (or whatever caused the group to split) gets resolved after the idle time. Then, the store would no longer hold the isolated member details (mnop) and again the merge will never take place. Using TCPGOSSIP requires gossip routers. But there are many practical cases where it is not desirable to add one more component (gossip routers) to the system, but still use JGroups across subnets that restrict multicast (PING cannot be used). TCPPING fits perfectly in such cases except for this issue. :-( > Problem with MERGE2 when not using multicast > -------------------------------------------- > > Key: JGRP-31 > URL: http://jira.jboss.com/jira/browse/JGRP-31 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN Java 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > > > Hi, > There is one case in which MERGE2 will fail while using TCPPING/UDP(without > mcast): > ======================================== > The initial_hosts property is "abc.com[7800];xyz.com[7801]". > These 2 machines are permanent group members (if they are up, they will be > members of the group). > Now there are numerous other programs on different machines that may > dynamically join and leave the group. These members are not known before hand > and cannot be specified in the initial_hosts property. > The members on abc.com and xyz.com are started and they join the same group. > Now another member from "mnop.com" starts and joins the group. The > co-ordinator will be abc.com > A network problem occurs and mnop.com is separated from abc.com and xyz.com > mnop.com forms its own single-member group with itself as the co-ordinator. > Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com > periodically checks on the initial_hosts list to see if they are up. It now > finds that abc.com is reachable and decides that abc.com is the leader (by > lexical sorting) and will take care of the merging. So it does not go ahead > with the merge. > On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check > if they can find members on the initial_hosts with a different co-ordinator. > Both of them never consider mnop.com as it is not in the initial_hosts list > So mnop.com will never be merged with the group. > ======================================== > Even the new MERGE3 & MERGEFAST protocols don't seem to help here. I checked > them out and found the following: > MERGEFAST works only if multicast is used, which is not my case. > MERGE3 just sends "I am co-ordinator" messages to a null destination. So in > the case where multicast is enabled, it goes to all possible members. But in > my case, with multicast disabled, the message will only be unicast to each > member of the current group. So in the above example, the "I am co-ordinator" > messages will never go to mnop.com after the network problem. > So even MERGE3 does not work in this case. -- 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
