Finally closed this OLD JIRA ! But better late than never

Documentation is at [1], chapter 5.18 of the Advanced part.

[1] http://www.jgroups.org/manual/html/user-advanced.html#MembershipChangePolicy

OK, done. All tests pass. Adding a section to the documentation before closing this issue...

The new merge policy tries to minimize moving the cordinator around (JGRP-1002). It works by picking the coordinator of the MergeView as the first elements of the sorted set of all subview coordinators. If we have {A,B,C}, {M,N,O} and {X,Y,Z}, then the new coordinator will be either A, M or X, but not any of the other members.
The rest of the subview ordering is left untouched, e.g. if we pick M as new coord, the MergeView will be {M,A,B,C,N,O,X,Y,Z}.

Actually, I take the above statement back

We can leave the basic tenet in place: the first element of the membership is always the coordinator ! We only make the way the membership is computed pluggable. This needs to be done in 2 places:

• When the coordinator determines the new membership
• When the coordinator is suspected and the next-in-line participant needs to determine whether it will become the new coordinator

We also need to make the computation of the new MergeView in Merger.MergeTask.run() pluggable

Implementing such a policy would be hard:

• The assumption that the first member of a view is the coordinator is a tenet of JGroups as had been in place for a long time
• Therefore, there is a lot of code which depends on this. Locating that code and changing it would be tedious
• Also, a lot of third party code depends on this as well

If we change this, the policy would therefore need to handle both the regular view change and a merge view change, but in both cases, the coordinator needs to be the first of the new view.

[Comment from JGRP-1002]
When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue

This would be useful from an operational perspective, for instance if the coordinator is designated to do some additional work, a pluggable policy will allow to know (predictably) what server is doing this work at any given time. Could be used to choose the "beefiest" server, for example.

Moved because this is new functionality, doesn't add to stability