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