[jboss-jira] [JBoss JIRA] Moved: (JBCLUSTER-275) Handle MergeViews in AbstractClusterLockSupport variants
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Tue May 25 18:49:54 EDT 2010
[ https://jira.jboss.org/browse/JBCLUSTER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list