Re: [jgroups-users] JGroups failing to give up on crashed coordinator

Questions/problems related to using JGroups <[email protected]> Tue, 13 Dec 2016 21:59:47 +0100
Newsgroups gmane.comp.java.javagroups.general
Message-ID <[email protected]>

On 13/12/16 20:31, Questions/problems related to using JGroups wrote:
> The most recent change in MERGE3 that I could find on the 3.6 branch was
> on Sept 15th and is already in my 3.6.11.Final library.  I don't see any
> code change for 2128 and it is marked as wontfix.

You're right, I looked at the wrong issue... the issue I was referring 
to is https://issues.jboss.org/browse/JGRP-2092, and that's in 3.6.11.

>  I will investigate whether I can get rid of Flush, my recollection is that I'm depending on
> it to prevent race conditions between the state transfer and other nodes
> modifying the state.

This is already done by the combination of BARRIER and STATE and the use 
of digests. FLUSH is merely the old stop-the-world protocol.

>  However I'm still concerned with the current
> JGroups behavior where a node will ignore a new view from its
> coordinator if it is not included in the view (by whatever root cause),
> and instead retain the old one which it already knows by definition is
> invalid.  Is there an expected case where this is recoverable?

If you sent me the views of all nodes at the time this happens, or even 
better, come up with a reproduceable scenario, I'll take a look.

Probe is your friend, also dump relevant state from STABLE and UNICAST3, 
NAKACK2.

>  Am I
> missing some other protocol that can recover from this?  I've had to put
> in quite a kludge to recover from this disastrous state.
>
> JT
>
> On Tue, Dec 13, 2016 at 9:02 AM, Questions/problems related to using
> JGroups <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Hi Jim,
>
>     I highly recommend *not* using FLUSH, as it was written a long time ago,
>     has never been really used in production and is prone to blocking! Do
>     you really need virtual synchrony?
>
>     Oftentimes, similar properties can be achieved using application level
>     mechanisms, e.g. TXs, or switching to total order (SEQUENCER).
>
>     Also note that MERGE3 got changed in 3.6.12 to cover an additional edge
>     case [1].
>
>     If you run into this again *without using FLUSH* and the MERGE3 from
>     3.6.12; I'll take a look...
>
>     [1] https://issues.jboss.org/browse/JGRP-2128
>     <https://issues.jboss.org/browse/JGRP-2128>
>
>
>
> ------------------------------------------------------------------------------
> 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