"manik.surtani(a)jboss.com" wrote : Ok, how about:
|
| * Provide a MergeHandler configuration
| * Defaults to IgnoreOnMerge, which does nothing. FlushOnMerge also provided, which
flushes in-memory state on merge
| * Allows users to write their own MergeHandlers, which are basically called when a
MergeView is received.
| * Users could also do something similar in a CacheListener's viewChange()
callback.
|
To make any kind of custom MergeHandler useful, JBC would need to expose an API to let the
handler get the info it needs from around the cache. That's likely to be a pretty
complex API.
anonymous wrote :
| But more important than this, how can an instance tell if there has been a split, and
it is not in the primary partition *before* a merge takes place? E.g., in your example of
{A,B,C} and {D,E}, how can instance E decide to shutdown and not process requests?
One way is the kind of static configuration Bela mentioned. User expect he a 5 node
cluster; declares 3 as the minimum primary partition size.
Another flawed way is tracking view size and when views change. As the view size
increases, keep recalculating your primary partition size. As view size decreases, check
how rapidly it's decreasing. A rapid decrease below the primary partition size ==
cluster split. A slow decrease == normal leaving of nodes, so recalc the primary
partition size.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084515#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...