[ http://jira.jboss.com/jira/browse/JGRP-781?page=all ] Bela Ban updated JGRP-781: -------------------------- Description: When we have the following situation, message B3 will not get delivered at A: - A and B - B sends 3 multicast messages: B1 (regular), B2 (OOB) and B3 (regular) - A receives B1, B3, B2 - A delivers B1 - B3 has to wait until B2 is received, so the thread returns - B2 is received, but since it is OOB, after pushing the message up the stack, the thread terminates ! ==> B3 will not get delivered until B4 is received ! The unit test case is OOBTest.testRegularAndOOBMulticasts() was: When we have the following situation, message B3 will not get delivered at A: - A and B - B sends 3 unicast messages: B1 (regular), B2 (OOB) and B3 (regular) - A receives B1, B3, B2 - A delivers B1 - B3 has to wait until B2 is received, so the thread returns - B2 is received, but since it is OOB, after pushing the message up the stack, the thread terminates ! ==> B3 will not get delivered until B4 is received ! For NAKACK, this is not critical as stability messages will fix the 'last message lost problem'. But, it would be nice to have the same solution to this problem also for NAKACK... -- 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

[ http://jira.jboss.com/jira/browse/JGRP-781?page=comments#action_12416408 ] Bela Ban commented on JGRP-781: ------------------------------- The solution was to keep a counter which is incremented when a regular message is *added*, but not *removed*, e.g. when a message arrives out of order. When (more than 1) messages are removed, the counter is decremented. When an OOB thread sees that the counter is > 0, it actually will remove and process the regular messages., otherwise it returns. This still allows OOB threads to block, but the chances are not much smaller. However, the ultimate solution is probably to have separate retransmission tables (AckReceiverWindow for UNICAST, NakreceiverWindow for NAKACK) to keep track of OOB and regular messages. -- 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