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