[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