geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Lund (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (GEODE-2391) change stop commands to be synchronous
Date Thu, 16 Feb 2017 18:15:41 GMT

     [ https://issues.apache.org/jira/browse/GEODE-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kirk Lund reassigned GEODE-2391:
--------------------------------

    Assignee: Kirk Lund

> change stop commands to be synchronous
> --------------------------------------
>
>                 Key: GEODE-2391
>                 URL: https://issues.apache.org/jira/browse/GEODE-2391
>             Project: Geode
>          Issue Type: Improvement
>          Components: gfsh
>            Reporter: Kirk Lund
>            Assignee: Kirk Lund
>
> Issuing a stop locator or stop server command will result in executing MemberMXBean#shutDownMember:
> {noformat}
> /**
>  * Shuts down the member. This is an asynchronous call and it will return immediately
without
>  * waiting for a result.
>  */
> @ResourceOperation(resource = Resource.CLUSTER, operation = Operation.MANAGE)
> public void shutDownMember();
> {noformat}
> Changing the stop commands to be synchronous (or as synchronous as possible) would be
a desirable improvement if we include an option for asynchronous shutdown, such as --async.
> Some options:
> 1) Gfsh could be changed wait for the process identified by that pid to terminate. This
would require gfsh to be running on the same machine and either tools.jar or jna.jar in the
classpath.
> 2) If the process being terminated is remote, then gfsh could be connected to a different
locator process and block until the stopped process departs the cluster of the locator that
gfsh is connected to. 
> This second approach would not work for the locator process itself if gfsh is connected
directly to it (unless it's local and tools.jar or jna.jar is in the classpath). Another possibility
is to have gfsh wait until the locator process kills its mbeanserver and rmi connection to
gfsh.
> 3) Another approach is to have gfsh wait for the pid file of the process that's being
stopped to be deleted. This requires gfsh to be running on a machine with visibility to the
same filesystem and for gfsh to know the working directory of the process being stopped.
> #1 is the most solid but has limited usability since gfsh has to be executing on the
same machine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message