[
https://jira.jboss.org/jira/browse/JGRP-940?page=com.atlassian.jira.plugi...
]
Bela Ban updated JGRP-940:
--------------------------
Summary: MERGE: issue with overlapping merges (NAKACK / UNICAST) (was: MERGE:
issue with merging)
Description:
Merge issue (see attached logs).
When we have {A,B,C} on (A, B and C) and {A,B,C,D} (on D) merging, the NAKACK information
for C might be incorrect due to the fact that D returned a digest containing old
information on C.
The issue for UNICAST is similar: D's UNICAST connection table was *not* cleared for
A, B or C because it never received a view change. However, A, B and C cleared their
UNICAST connection table of D because they excluded D.
After a merge, D's unicasts to the other partition (and vice versa) will likely fail
because D's UNICAST connection tables for A, B and C still contains the old sequence
numbers, but the ones for A, B and C start with #1 again !
A possible solution for NAKACK is to verify we handle digests for overlapping partitions
OK, and for UNICAST, we'll might have to introduce a seqno agreement protocol, ie.
tagging the first seqno as first=true.
A more detailed description will follow.
was:
Merge issue (see attached logs).
When we have {A,B} and {C,D}, A ignores its own portion of the digest {A,B,C,D} on a
merge, and installs B, C and D. However, maybe it should ignore the digest information for
*all* members it knows about, in this case B as well.
Investigate
MERGE: issue with overlapping merges (NAKACK / UNICAST)
-------------------------------------------------------
Key: JGRP-940
URL:
https://jira.jboss.org/jira/browse/JGRP-940
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.10, 2.8
Merge issue (see attached logs).
When we have {A,B,C} on (A, B and C) and {A,B,C,D} (on D) merging, the NAKACK information
for C might be incorrect due to the fact that D returned a digest containing old
information on C.
The issue for UNICAST is similar: D's UNICAST connection table was *not* cleared for
A, B or C because it never received a view change. However, A, B and C cleared their
UNICAST connection table of D because they excluded D.
After a merge, D's unicasts to the other partition (and vice versa) will likely fail
because D's UNICAST connection tables for A, B and C still contains the old sequence
numbers, but the ones for A, B and C start with #1 again !
A possible solution for NAKACK is to verify we handle digests for overlapping partitions
OK, and for UNICAST, we'll might have to introduce a seqno agreement protocol, ie.
tagging the first seqno as first=true.
A more detailed description will follow.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira