Re: [jgroups-users] problem with cluster merge after startup user error

On 06/04/18 14:05, Questions/problems related to using JGroups wrote:
> 
>         This causes some problems for us because B doesn't perform
>         non-coordinator tasks that should have happened at startup, and
>         it could be very confusing to users to try to debug why they
>         don't have an A/B cluster and suddenly they do. Also sometimes B
>         becomes the coordinator, which could affect starting other
>         nodes. (Either way, they both have incorrect copies of the
>         cluster state shared with STATE_TRANSFER.)
> 
>         Do you have a suggested way to change our setup so that, once A
>         and B start and don't find each other, they stay that way?
> 
> 
>     That's kind of a strange requirement and I'm not sure I
>     understand... You could dynamically remove TCPPING and/or MERGE3
>     from the running node and thus disable merging. But don't you want
>     the 2 nodes to eventually end up in the same cluster?
> 
> 
> In the startup case only, I'd prefer that they didn't so that the user 
> knows something was set incorrectly. Part of our startup is that new 
> nodes start, join, see that they're not the coordinator and send some 
> info to the coordinator, who then updates some state info and tells 
> everyone else to run a jChannel.getState(). If someone starts the nodes 
> both as coordinators and then they merge, they both have their own 
> cluster state, missing info from the other. We have code that runs X 
> seconds after any view change to catch unexpected problems like this and 
> fix the state, but it would turn the cluster startup into a confusing, 
> several minute process instead of a few seconds. It's not the end of the 
> world, but I'd prefer some way to just tell them "you're not doing it 
> right" and have them fix it and restart.

Do you always know whether the started node is supposed to be the first 
in the cluster (coordinator), or not? In the coord case, you're 
expecting a view of 1. In the follower (participant) case, you're 
expecting a view > 1, and can go into an error state if that's not the case.

Of course, if you don't know this, then all of these assumptions are moot.

> (Note, once everything does reach steady state, we will have overwritten 
> their initial_hosts data with the correct info, so it will "just work" 
> on subsequent cluster starts.)

OK, I assume you're persisting this information? Note that you could 
also use PDC to handle this part.

> I'm guessing that anything I do to prevent startup merges would prevent 
> future merges also from the above, and that would be bad. Is that right? 

Depends on what you do. If you disable merging at startup and enable it 
at runtime (e.g. by enabling MERGE3), then that might achieve what you 
want to do.

> Plan B: is there a way during a view change that I can detect that it's 
> a merge?

Yes: the actual argument to viewAccepted(View v) is a MergeView 
(subclass) rather than a View.

> Then I could do our cluster state check right away instead of X 
> seconds later, at least saving some time. If I could also speed up how 
> often the discovery request happens that could help, unless it causes 
> other issues.

I'm still not sure I grok what you want to do. If you want to do an IRC 
chat, I can be found on #jgroups.
Cheers

> Thanks,
> Bobby
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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 | 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
_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users