[
http://jira.jboss.com/jira/browse/JGRP-699?page=comments#action_12400704 ]
Bela Ban commented on JGRP-699:
-------------------------------
Scrap that ! If we have
A --> A,B,C
B --> B,C
C --> B,C
(A was shunned), then we will *not* have aauthoritative answer from C, just from A and B
!
A better solution is simple:
- Just merge all digests, so we end up with A:23, B:12, C:5
- We can reason that no member P will see a seqno SEQ from sender S higher than the one
from S
itself, so the S always (indirectly) ends up being the authoritative source, because we
MAX highest
delivered seqnos
- However, we *have* to replace existing digest entries, and cannot simply skip them, as
it is currently
done
NAKACK: merging of digests is incorrect
---------------------------------------
Key: JGRP-699
URL:
http://jira.jboss.com/jira/browse/JGRP-699
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4, 2.4.1, 2.4.1 SP1, 2.4.1 SP2, 2.4.1 SP3, 2.4.1 SP4, 2.4.2
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7, 2.6.3, 2.4.3
The merge view is:
2008-02-20 23:49:30,872 DEBUG [org.jgroups.protocols.pbcast.GMS]
view=MergeView::[172.16.172.233:19382|3] [172.16.172.233:19382, 172.16.172.234:19382],
subgroups=[[172.16.172.233:19382|1] [172.16.172.233:19382, 172.16.172.234:19382],
[172.16.172.234:19382|2] [172.16.172.234:19382]],
digest=172.16.172.233:19382: [557 : 564(564)], 172.16.172.234:19382: [901 : 923 (923)]
So, the digest for 234:19382 is 901-923, which means 234 could actually satisfy the
retransmit request below. However, when the xmit req arrives:
2008-02-20 23:49:32,004 ERROR [org.jgroups.protocols.pbcast.NAKACK]
(requester=172.16.172.233:19382, local_addr=172.16.172.234:19382)
message 172.16.172.234:19382::919 not found in retransmission table of
172.16.172.233:19382:[557 : 565 (565)]
172.16.172.234:19382: [921 : 924 (924) (size=3, missing=0, highest stability=921)]
, we can see that now the digest for 234:19382 is 921-924.
In 2.4, the merge algorith for digests (NAKACK.mergeDigest()) takes the *max* of the low
seqnos (MAX(901,921), in 2.5 and higher we don't touch an existing entry, so the
digest for 234:19382 would still be 901-923, and we could therefore satisfy the merge
request.
SOLUTION: use the solution implemented in 2.5 and higher: don't set digests for
existing entries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira