]
Bela Ban commented on JGRP-1251:
--------------------------------
To reproduce:
- Take udp.xml and add <DISCARD use_uid="true"/> on top of UDP
- Run 2 Draw instances with -props /yourlocation/udp.xml -state
- Draw something in both instances
- Start a partition by clicking on "Start discarding messages" in 1 instance
- Once the cluster has fallen apart, clear both instances and draw something again
- The make the partition disappear by clicking on "Stop discarding messages"
- The 2 members will merge, but drawing in 1 of them causes that member not to receive any
updates
"probe.sh op=NAKACK.printDigestHistory" will show that the unresponsive member
asks itself for retransmission and it doesn't deliver its own messages
NAKACK: overwriteDigest() doesn't adjust sequence number
--------------------------------------------------------
Key: JGRP-1251
URL:
https://jira.jboss.org/browse/JGRP-1251
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.10.2, 2.12
NAKACK.overwriteDigest() is used by the 2 state transfer protocols (STATE_TRANSFER and
STREAMING_STATE_TRANSFER).
When A has a digest A:250,B:10,C:160, and gets the state (as a result of calling
JChannel.getState() with a digest of A:230,B:10,C:160, it'll set its own digest to
A:230 (from A:250).
However, A's sequence number (seqno) will remain at 250 ! This means, when A sends
the next message, it'll send A:251, but because we set the digest to A:230, A will ask
itself to retransmit messages A:230-250 !
SOLUTION: when receiving digest A:230, A should set its seqno to 230
WORKAROUND: use FLUSH, which doesn't ship digests on state transfer
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: