It looks like there is consensus to move this RFC forward and we are past
the to be reviewed by date. I'll go ahead and move this RFC into the "Under
Developement" state. Thanks all who provided feedback! If you have
additional feedback, we'll still be watching the RFC and this thread for
further c
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:70
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 wrote:
> Hello All,
>
> I would like to propose that we make the gfsh “stop server” command
> synchronous. It is causing some issues with some
`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
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
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 lik
@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 ca
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 Stol
@Mike - Who said anything about...
"*masking it in an early return from the shutdown command doesn't seem like
the appropriate action.*"
I think you missed the point. You explicitly have to break out of the
wait, which is a conscious decision when *Gfsh* is run interactively.
The command as I p
I think this cache.close() discussion is off topic. I’m not sure that’s the
case, but it’s not at the root of my question.
The problem: Using gfsh -e, from a gfsh rule in test, stop server does not
properly block as the rest of the api seems to.
I’m looking for a better understanding of the de
10 matches
Mail list logo
