This adds the ability to let application code create the new View on a join, leave or crash-leave, or the MergeView on a merge.
Why is this important ?
There are 2 scenarios that benefit from this:
- The new default merge policy always picks a previous coordinator if available, so that moving around of the coordinatorship is minimized. Because singleton services (services which are instantiated only on one node in the cluster, usually on the coordinator) need to shutdown services and start them every time the coordinatorship moves, minimizing this means less work for singletons.
- A node with a coordinator role has more work to do, e.g. join/leave/merge handling, plus it may be running some singleton services. Some systems will therefore prefer bulkier machines (faster CPU, more memory) to run the coordinator. But so far, this hasn't been possible, as JGroups always preferred every node equally. This changes now, and the puggable policy allows for pinning the coordinatorship to a number of machines (a subset of the cluster nodes).
Cheers,
[1] https://issues.jboss.org/browse/JGRP-592
[2] http://www.jgroups.org/manual/html/user-advanced.html#MembershipChangePolicy
No comments:
Post a Comment