[ https://jira.jboss.org/jira/browse/JGRP-981?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-981: -------------------------- Fix Version/s: 2.4.7 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-981?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-981: ------------------------------- Note that VIEW_SYNC was added to JGroups in 2.2.9: https://jira.jboss.org/jira/browse/JGRP-136 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-981?page=com.atlassian.jira.plugi... ] Dennis Reed commented on JGRP-981: ---------------------------------- Brian's hypothesis on the cause is correct. On the node with the wrong view, a TRACE log did contain the "view ... is discarded as we are not a participant" message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-981?page=com.atlassian.jira.plugi... ] Dennis Reed commented on JGRP-981: ---------------------------------- I started with stock EAP 4.3 CP04. # from $JBOSS_HOME/server cp -R all concurrent1 cp -R all concurrent2 cp -R all concurrent3 and started them with the script: ~/jboss/bin/run.sh -c concurrent1 -b127.0.0.1 > /dev/null 2>&1 & ~/jboss/bin/run.sh -c concurrent2 -b127.0.0.2 > /dev/null 2>&1 & ~/jboss/bin/run.sh -c concurrent3 -b127.0.0.3 > /dev/null 2>&1 & -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-981?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-981: ------------------------------- OK, I was able to reproduce this here withy a simple Draw demo. What happens is: 1. Start A, becomes coordinator. V1={A} 2. Start B and C concurrently 3. A processes B's JOIN request and sends back V2={A,B} to B 4. B is in the process of installing this view but hasn't yet changed to Participant (from Client) 5. A processes C's JOIN request and sends back V3={A,B,C} to C 6. A multicasts V3={A,B,C} to the group 7. Since B is still a Client (ClientGmsImpl), it discards V3 8. Therefore B is stuck with V2 and won't install V3 until prodded by VIEW_SYNC This is fixed in 2.6 and later: the coordinator waits until it has acks from all members in which a new view is installed, e.g. we would wait in step #4 until the Client becomes a Participant, and therfore not drop V3. In case we exceed the view_ack_collection_timeout, VIEW_SYNC will install the correct view. A clear WORKAROUND is to stagger startup of multiple nodes, all that's needed is a few hundred ms [1] https://jira.jboss.org/jira/browse/JGRP-937 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira