[JBoss JIRA] Resolved: (MODCLUSTER-66) HAModClusterService needs to handle cluster splits
by Paul Ferraro (JIRA)
[ https://jira.jboss.org/jira/browse/MODCLUSTER-66?page=com.atlassian.jira.... ]
Paul Ferraro resolved MODCLUSTER-66.
------------------------------------
Resolution: Done
Leverages new PING command to verify the livelihood of a dead member. If ping fails, only then is a REMOVE-APP * command sent on behalf of the dead member.
> HAModClusterService needs to handle cluster splits
> --------------------------------------------------
>
> Key: MODCLUSTER-66
> URL: https://jira.jboss.org/jira/browse/MODCLUSTER-66
> Project: mod_cluster
> Issue Type: Task
> Affects Versions: 1.0.0.Beta4
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Fix For: 1.1.0.CR1
>
>
> The case where a split of the JGroups group occurs but nodes are still able to contact the httpd servers needs to be handled. There is a brief discussion of this on https://www.jboss.org/community/docs/DOC-11431 under "Split-Brain Syndrome". Problem is split-brain will result in nodes removing each other from httpd, resulting in no nodes active.
> The wiki page describes a simple approach. A more complex approach would be to take a "primary partition" approach, whereby say an initial cluster of size n==6 {A, B, C, D, E, F} splits into two cluster {A, B, C, D} and { E, F}. To continue to handle requests a partition would need to have at least Math.floor((float) n / 2 + 1) members.
> What kind of approach is appropriate would probably depend on the deployed webapps and how they interact with the cluster. If there is no clustered state that can become inconsistent across the cluster split, the simple approach described on the wiki can work fine (an HAModClusterService master doesn't disable a node if httpd reports it is still available). If there is shared state that needs to remain consistent (e.g. a clustered Hibernate Second Level Cache) then primary partition works better.
> Most likely this overall problem will be resolved in stages, e.g. the simple approach from the wiki first.
--
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
15 years, 2 months
[JBoss JIRA] Created: (MODCLUSTER-85) HAModClusterService can throw NullPointerExceptions after a partition merge
by Paul Ferraro (JIRA)
HAModClusterService can throw NullPointerExceptions after a partition merge
---------------------------------------------------------------------------
Key: MODCLUSTER-85
URL: https://jira.jboss.org/jira/browse/MODCLUSTER-85
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.0.0.GA
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Priority: Minor
This is caused by updateClusterStatus rpcs returning null if a merged node has master status.
Make sure all rpcs get the same treatment.
2009-07-27 14:29:48,134 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] (Incoming-20,10.248.107.114:32770) New cluster view for partition DefaultPartition: 4 ([10.240.62.47:1099, 10.248.107.114:1099, 10.249.195.196:1099] delta: 2)
2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Merging partitions...
2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Dead members: 0
2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Originating groups: [[10.240.62.47:32769|3] [10.240.62.47:32769, 10.249.195.196:32769], [10.248.107.114:32770|0] [10.248.107.114:32770]]
2009-07-27 14:29:50,878 ERROR [org.apache.catalina.core.ContainerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Exception invoking periodic operation:
java.lang.NullPointerException
at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.updateClusterStatus(HAModClusterService.java:896)
at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.status(HAModClusterService.java:836)
at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.status(HAModClusterService.java:781)
at org.jboss.modcluster.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:157)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1348)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1612)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1601)
at java.lang.Thread.run(Thread.java:636)
--
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
15 years, 2 months