]
Brian Stansberry moved JBAS-7272 to JBCLUSTER-275:
--------------------------------------------------
Project: JBoss Clustering (was: JBoss Application Server)
Key: JBCLUSTER-275 (was: JBAS-7272)
Component/s: HA-Server-API
(was: Clustering)
Fix Version/s: (was: 6.0.0.M4)
Handle MergeViews in AbstractClusterLockSupport variants
--------------------------------------------------------
Key: JBCLUSTER-275
URL:
https://jira.jboss.org/browse/JBCLUSTER-275
Project: JBoss Clustering
Issue Type: Task
Security Level: Public(Everyone can see)
Components: HA-Server-API
Reporter: Brian Stansberry
Assignee: Brian Stansberry
org.jboss.ha.framework.server.lock.AbstractClusterLockSupport and/or its subclasses need
to deal with cluster merges, i.e. AS instances in groups {A, B} and {C, D} discover each
other and form a single group {A, B, C, D}. Following a merge, it's possible a node in
each of the merged subgroups thinks it has the cluster wide lock.
A simple approach that *may* work in all cases is to handle a merge by having each node
abandon the cluster-wide lock, forcing the next attempt by a local caller to re-acquire
the lock. Need to think through though whether that is the correct semantic in all cases.
AbstractClusterLockSupport needs to implement HAExtendedMembershipListener instead of
just HAMembershipListener; this will allow it to know whether a view change was due to a
merge.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: