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

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.  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.  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?  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]> 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
>
>

------------------------------------------------------------------------------
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