"bstansberry(a)jboss.com" wrote :
|
| 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.
|
This does not necessarily need to be provided by JBossCache; you could have an external
service (e.g. an RpcDispatcher/ClusterPartition running on a Multiplexer), and fetching
the necessary information *outside of JBossCache*.
anonymous wrote :
| 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.
That's a bit non-deterministic, what is *slow* ? It is as sloppy as using timeouts...
Any policy works to pick the primary partition, as long as it is deterministic. Note that
here we're not just talking about *MergViews* but regular *Views* as well !
For example, a SplitBrainPolicy for primary partition could be
- 3 members or more
OR
- Host A is part of the view
I think this works pretty well, for views and merge views. When not in the primary
partition, we could shut down the node. Ie. disconnect from the channel, disable the
Connector (in JBossWeb) and/or send 404 or some HTTP error codes back to mod_jk so Apache
knows not to send any more requests to this node.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084521#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...