TP has a check whether the dest of incoming unicast messages matches its local address (or the local address in the ProtocolAdapter if a shared transport is used). Messages whose dest != local address are dropped.
However, in the following scenario, we can have spurious warnings for 2 minutes (by default):
- 2 processes with 2 members on a shared transport each (see attached shared.xml and bla3.java)
- Start 2 bla2 instances on the same box
- On the second instance, a member leaves and immediately rejoins (press [2] on the second member)
- For some reason, the leaving member didn't receive the LEAVE_RSP unicast message from the coordinator (first member)
- The newly joined member now receives the LEAVE_RSP unicast from the coordinator, but now it is a different member and therefore has a different local address, so we see the warning
- This will continue for 2 minutes, until the connection to the unknown member is closed by the coordinator (configurable)
TODOs:
- Investigate why the LEAVE_RSP unicast is not received by the leaving member
- In the warning, add the sender's address and print the headers of the message so it's easier to find the culprit
- incorporates
-
WFLY-2632 JGroups drops unicast messages after shutdown/restart (dropping unicast message to wrong destination)
- Closed