[ 
https://issues.apache.org/jira/browse/GEODE-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431370#comment-16431370
 ] 

ASF subversion and git services commented on GEODE-4995:
--------------------------------------------------------

Commit 2e89e840f040800a65721c161d3b4203acfd7ff0 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2e89e84 ]

GEODE-4995 ClusterStartupRule is inefficient when shutting down the cluster

modified after() to shut down non-locators before shutting down locators,
allowing membership coordination to stay in the locator instead of
causing cascading movement of the role.


> ClusterStartupRule is inefficient when shutting down the cluster
> ----------------------------------------------------------------
>
>                 Key: GEODE-4995
>                 URL: https://issues.apache.org/jira/browse/GEODE-4995
>             Project: Geode
>          Issue Type: Test
>          Components: tests
>            Reporter: Bruce Schuchardt
>            Assignee: Bruce Schuchardt
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> ClusterStartupRule is often used to create a locator and some number of 
> servers, ignoring the locator started by DUnitLauncher.  This is inefficient 
> but it's probably intentional and can be avoided by configuring the servers 
> to use the DUnitLauncher's locator.
> However, when shutting down the cluster it is managing ClusterStartupRule 
> shuts down the VMs in order starting with vm0.  If vm0 happens to be the 
> membership coordinator this causes membership to create a new coordinator in 
> vm1 and causes distributed lock grantor state to also fail over to vm1.  Then 
> vm1 is shut down, causing services to fail over to vm2. Etc.
> ClusterStartupRule should be modified to shut down non-locator VMs first and 
> then shut down locator VMs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to