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

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

(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.)

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?
Plan B: is there a way during a view change that I can detect that it's a
merge? 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.

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