[jboss-jira] [JBoss JIRA] Updated: (JBAS-7272) Handle MergeViews in AbstractClusterLockSupport variants

[Brian Stansberry (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7272:
-----------------------------------

    Fix Version/s: JBossAS-6.0.0.CR1
                       (was: JBossAS-6.0.0.M3)


> Handle MergeViews in AbstractClusterLockSupport variants
> --------------------------------------------------------
>
>                 Key: JBAS-7272
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7272
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.CR1
>
>
> 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/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira