What we ended up doing was to turn off the Merge completely for the cache and
tap into the JChannel that JBoss uses to detect when the network goes down and
comes back. By using an HAMembershipExtendedListener attached to the
ClusterPartition MBean we get notification when there is a membership
Well, you can catch the viewAccepted() callback and check whether the argument
is a View (no merge) or a MergeView (merge). In the latter case, do what you
need to do. To prevent the cache from handling the merge itself, you may need
to subclass TreeCache and override the callback
View the orig
Actually, that is the plan: when node C detected the merge, it would exit with
a status code of 10 thus causing a restart of JBoss. C would then join the
cluster as a new node. That part of it WAS working. When I commented out the
MERGE2 entry in the xml file, it stopped the cache from merging j
Shunning *always* rejoins C. To prevent this:
- disable shunning
- Remove MERGE2 from the stack
But I'm not sure I recommend this, unless you have a way of killing C, because
{A,B} and {C} will see each other's traffic and discard it
View the original post :
http://www.jboss.com/index.html?modu
I have gained access to the JChannel for the PojoCache and executed the
following:
channel.setOpt(Channel.AUTO_GETSTATE, Boolean.FALSE);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.FALSE);
However, this doesn't seem to have any effect. When I reconnect the network
cable (for node
I am also thinking that AUTO_RECONNECT is true when I want it to be false.
Since PojoCache doesn't provide access to its JGroup, how would I gain access
to this to be able to change it?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978613#3978613
Reply to t
