[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

bstansberry@jboss.com do-not-reply at jboss.com
Fri Sep 14 11:10:01 EDT 2007


"manik.surtani at 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#4084515

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084515



More information about the jboss-dev-forums mailing list