Its a good option. But do we see any use-cases, where user doesn't want to wait for a server stop (if its taking long time) and continue to proceed with other operation (say executing commands on other servers). Also, i could not make out how this is related to GEODE-7017; the testcase seems to be related to starting the server...
-Anil. On Tue, Sep 10, 2019 at 3:32 PM John Blum <jb...@pivotal.io> wrote: > `stop server` is synchronous (with an option to break out of the wait using > CTRL^C) AFAIR. > > Way deep down inside, it simply relies on GemFireCache.close() to return > (in-process). > > As Darrel mentioned, there is not "true" signal the the server was > successfully stopped. > > -j > > > On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider <dschnei...@pivotal.io> > wrote: > > > I think it would be good for stop server to confirm in some way that the > > server has stopped before returning. > > > > On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson <mhan...@pivotal.io> wrote: > > > > > Hello All, > > > > > > I would like to propose that we make the gfsh “stop server” command > > > synchronous. It is causing some issues with some tests as the rest of > the > > > calls are blocking. Stop on the other hand immediately returns by > > > comparison. > > > This causes issues as shown in GEODE-7017 specifically. > > > > > > GEODE:7017 CI failure: > > > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest > > > > startupReportsOnlineOnlyAfterRedundancyRestored > > > https://issues.apache.org/jira/browse/GEODE-7017 < > > > https://issues.apache.org/jira/browse/GEODE-7017> > > > > > > > > > What do people think? > > > > > > Thanks, > > > Mark > > > > > -- > -John > john.blum10101 (skype) >
