[jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-275) Handle MergeViews in AbstractClusterLockSupport variants
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Mon Jul 11 16:03:24 EDT 2011
[ https://issues.jboss.org/browse/JBCLUSTER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Stansberry reassigned JBCLUSTER-275:
------------------------------------------
Assignee: (was: Brian Stansberry)
> Handle MergeViews in AbstractClusterLockSupport variants
> --------------------------------------------------------
>
> Key: JBCLUSTER-275
> URL: https://issues.jboss.org/browse/JBCLUSTER-275
> Project: JBoss Clustering
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: HA-Server-API
> Reporter: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list