Re: [jgroups-users] Unexpected Merge, Coordinator in multiple partitions

Questions/problems related to using JGroups <[email protected]> Wed, 5 Apr 2017 11:24:58 +0200
Newsgroups gmane.comp.java.javagroups.general
Message-ID <[email protected]>
This always worked for me (5 out of 5 times), but takes a long time. The 
reasons are:

- You use FD rather than FD_ALL which takes longer to detect multiple 
failures than FD_ALL.
I replaced FD with <FD_ALL timeout="3000" interval="1000" 
timeout_check_interval="1500"/> and things got better

- 3.6.13.Final made things faster; I guess [1] made an impact

- The timeouts in MERGE3 are such that the merge detection will happen 
anywhere between 10 and 30 seconds; sometimes 2 merge detections are 
needed to detect an edge case as this one, meaning it will take between 
20 and 60 seconds for a merge to start. The merge itself should only 
take a few milliseconds.

- The reason C never excluded A and B is that, while A and B were 
rejecting messages from C, C was *not* rejecting messages from A and B 
and thus never suspected them. Had you set DISCARD.discard_all=true in 
C's discard protocol, C would have excluded A and B, leading to the 
following views:
A: AB
B: AB
C: C

Instead, the views you got were:
A: AB
B: AB
C: ABC

This exact scenario is covered by unit test OverlappingMergeTest.

[1] https://issues.jboss.org/browse/JGRP-2092

On 04/04/17 16:05, Questions/problems related to using JGroups wrote:
> Hi JGroups Users,
>
> We have seen an unexpected Merge View in one of our deployments, where the coordinator is in multiple partitions.
> And I am not really sure if this is a bug or a feature (TM).
>
> The situation is like this:
> Members: [A,B,C]
> Subgroup 1: [A,B,C]
> Subgroup 2: [A,B]
>
> We would have expected to see:
> Members: [A,B,C]
> Subgroup 1: [A,B]
> Subgroup 2: [C]
>
> It also looks like Node C has been isolated from A,B but the isolation ended before Node C changed its View.
> With a View like this is it hard on Node C to detect that there has been a certain change in the topology,
> especially if the coordinator (A) is in the major and in the minor partition.
>
> Has anyone seen similar behaviour or an idea how to prevent a Merge situation like this ?
>
> A small example project which reproduces the mentioned behaviour can be downloaded here:
> https://www.dc-square.de/wp-content/uploads/jgroups-test.zip
>
>
> Regards,
> Christoph
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot