[
http://jira.jboss.com/jira/browse/JGRP-505?page=comments#action_12364386 ]
Bela Ban commented on JGRP-505:
-------------------------------
Okay, I now think this is a race issue between the merge view (multicast) and the
reception of the subsequent message (unicast). Not sure how to solve this as unicast and
multicasts are not related ordering wise.
I'm looking further into this
UNICAST: sequence numbering after merge leads to messages never being
delivered
-------------------------------------------------------------------------------
Key: JGRP-505
URL:
http://jira.jboss.com/jira/browse/JGRP-505
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.5
During refactoring of TUNNEL to use TP I ran MultiplexerMergeTest very often. This test
basically consists of two members A and B that are exchanging message through
GossipRouter. When GossipRouter is killed members form their own subgroups that are
subsequently merged once router starts again.
I noticed that on very rare occasions (1 in 20 test runs) one of the members (say A)
stops passing up unicast messages from B above UNICAST protocol. More detailed logging and
inquiry at UNICAST revealed that upon merge A stops passing up messages from B and keeps
adding messages from B seq>1 into B's window but does not pass up messages further
since message seq B1 is missing. After further investigation I concluded that message B1
must have been delivered to A prior to MergeView. MergeView wiped clean all windows and
added next sequence B2 to appropriate window.
I am not sure if this is only applicable to Multiplexer setup. The issue is hard to
reproduce. I will see if it is possible to make a unit test to reproduce it.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira