[
https://jira.jboss.org/browse/JGRP-1251?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1251:
--------------------------------
To reproduce:
- Run "java org.jgroups.tests.GroupCommunication A"
- Start a 2nd instance: B
- Click on "Start discarding" in both dialogs
- When the cluster has fallen into 2 singleton clusters, click on "Stop
discarding" in both dialogs
- The merge will happen, but the state transfer screws up the seqnos (probably related to
incorrect digests)
Error:
2327 [WARN] NAKACK: (requester=B, local_addr=A) message A::4 not found in retransmission
table of A:
[0 : 3 (3)]
2926 [WARN] NAKACK: (requester=B, local_addr=A) message A::4 not found in retransmission
table of A:
[0 : 3 (3)]
Note that, when we send another message (by typing something into the shell of A), the
retransmission message disappears, because the message #4 is now available.
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.11.1, 2.12
Attachments: GroupCommunication.java, tmp.xml, ViewHandler.java
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.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira