]
Bela Ban resolved JGRP-1802.
----------------------------
Resolution: Done
OverlappingUnicastMergeTest fails to receive all messages
---------------------------------------------------------
Key: JGRP-1802
URL:
https://issues.jboss.org/browse/JGRP-1802
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Environment: Solaris, RHEL
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.2.13
OverlappingUnicastMergeTest does the following:
- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it;
if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which
should be recovered from
- send messages to the channels and check that the messages are received, despite the
injected view
OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the
test methods are failing within the test class on multiple platforms.
What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}
What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11
ucasts for B:
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg
#4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C:
unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5
from C
{noformat}
The order here is the order in which the unicasts were received from all three senders by
the single receiver. For example, in the above, in testWithViewBC, channel A should
receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from
channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: