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