[
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)
