Is it possible for a channel which was marked as suspect (and removed from the view) to rejoin automatically?

[dan-badham-rft]

Is it possible for a channel which was marked as suspect (and removed from the view) to rejoin automatically?

Say we have a view {A, B ,C} , and nodes A & B believe that C is down, A does the verify (and confirms that C is down) and publishes a new view of {A, B}.

However, node C is not down (it was just unresponsive), and receives the view changed event, we know that this is the case as we see the following in C's logs:

JGroups/src/org/jgroups/protocols/pbcast/GMS.java

Line 627 in 0df6b94

log.warn("%s: not member of view %s; discarding it", local_addr, new_view.getViewId());

What state is C now in? Will it be able to recover automatically and be included in a new view update? If so, how does this process work?

Thanks,
Dan

[rhusar]

channel which was marked as suspect

It's not a channel that is suspected, it's a member that is suspected.

Will it be able to recover automatically and be included in a new view update?

That's what merging does, see: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/MERGE3.java

[dan-badham-rft]

Thanks for the info @rhusar

Does MERGE3 work when a single member is unresponsive for a period of time and then recovers (say we had lots of back to back long GC pauses), but that member itself seems to think that it is still part of the group?

In my scenario I do not see any calls into receiverAdapter.viewAccepted , which suggests to me that member C hasn't decided that it is now within a singleton subgroup where it is the coordinator.

[rhusar]

Does MERGE3 work when a single member is unresponsive for a period of time and then recovers (say we had lots of back to back long GC pauses), but that member itself seems to think that it is still part of the group?

Eventually - it will kick in once the group splits into 2 (sub)clusters.

In my scenario I do not see any calls into receiverAdapter.viewAccepted , which suggests to me that member C hasn't decided that it is now within a singleton subgroup where it is the coordinator.

This is most likely just timing and it will eventually realize its in a singleton cluster and install the view as well. You can tweak protocol configuration to remove an overloaded member more promptly if that's an issue.