OverlappingUnicastMergeTest --------------------------- 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.