[jboss-jira] [JBoss JIRA] Updated: (JGRP-940) MERGE: issue with overlapping merges (NAKACK / UNICAST)

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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