[ https://jira.jboss.org/jira/browse/JGRP-1111?page=com.atlassian.jira.plug... ] sean chandler updated JGRP-1111: -------------------------------- Attachment: jgroups_broken.xml -- 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-1111?page=com.atlassian.jira.plug... ] sean chandler updated JGRP-1111: -------------------------------- Description: Draw demo does not work in conjunction with state transfer, sequencer, and flush in the stack. Nodes will join initially and form a cluster. Killing master node puts the survivor in an infinite flush block. The killed node will never join the cluster again. Bug is not present in version 2.8.0CR6. Reproduce: Start two nodes using the command lines below. Draw on both panels. Kill master node. Draw on survivor. Bring up killed node. Infinite flush block (regardless of flush timeout). Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface x.x.x.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1 0.0.0.0 x.x.x.x.254 0.0.0.0 UG 0 0 0 eth0 node0> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.1 org.jgroups.demos.Draw -state -props jgroups.xml node1> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.2 org.jgroups.demos.Draw -state -props jgroups.xml was: Draw demo does not work in conjunction with state transfer, sequencer, and flush in the stack. Nodes will join initially and form a cluster. Killing master node puts the survivor in an infinite flush block. The killed node will never join the cluster again. Reproduce: Start two nodes using the command lines below. Draw on both panels. Kill master node. Draw on survivor. Bring up killed node. Infinite flush block (regardless of flush timeout). Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface x.x.x.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1 0.0.0.0 x.x.x.x.254 0.0.0.0 UG 0 0 0 eth0 node0> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.1 org.jgroups.demos.Draw -state -props jgroups.xml node1> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.2 org.jgroups.demos.Draw -state -props jgroups.xml -- 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-1111?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1111: -------------------------------- OK, I'll take a look, too, because removal of SEQUENCER fixes the issue... It might be a SEQUENCER, not a FLUSH issue -- 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-1111?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1111: -------------------------------- The problem is in SEQUENCER.broadcast(): a message broadcast on behalf of someone else is copied, but the headers are *not* copied. This means that a STOP-FLUSH header is NOT copied and therefore won't ever be received by anyone else ! The simple solution is to copy the headers, too. But I need to investigate whether this doesn't have other ramifications, for example what if we copy UNICAST or NAKACK headers ? The forwarded message is a unicast, but is sent as a multicast by the coord: won't the presence of a UNICAST header lead to it being processed as a unicast *and* multicast message ? Maybe the better solution is to wrap a forwarded message in the payload... -- 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-1111?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1111: -------------------------------- Fixed in CVS head, backported to 2.6 branch, running tests on 2.6... -- 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