I understand that issue John, but masking it in an early return from the shutdown command doesn't seem like the appropriate action. Maybe we should consider that nearly all gfsh commands are not blocking, and rather, have a way to determine which ones are still waiting for completion?
-- Mike Stolz Principal Engineer, Pivotal Cloud Cache Mobile: +1-631-835-4771 On Tue, Sep 10, 2019 at 9:13 PM John Blum <jb...@pivotal.io> wrote: > @Anil- I hear your argument when you are "scripting" with *Gfsh*, but > blocking absolutely maybe less desirable when using *Gfsh* interactively. > There are, after all, many non-cluster based commands. > > @Mark - I see. I have generally found in my own testing purposes, > especially automated, that a cache instance is not fully closed and has not > properly released all it's resource even after cache.close() returns. > > -j > > On Tue, Sep 10, 2019 at 5:02 PM Mark Hanson <mhan...@pivotal.io> wrote: > > > 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) > > > > > > -- > -John > john.blum10101 (skype) >
