Hi John, Kirk and I found that in our testing it was returning before it was fully stopped. I have a change that seems viable that waits for the pid file to disappear from the subdirectory of the server. I am not a fan. I would prefer to wait for the pid to disappear, but that doesn’t seem like it will be cross-platform friendly.
Thanks, Mark > On Sep 10, 2019, at 3:31 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)
