Good question. I will have to look into that.
Thanks,
Mark
> On Sep 11, 2019, at 10:53 AM, Dan Smith wrote:
>
>> The idea I am working with at the moment that Kirk pointed me at was to
> use the pid file in the directory as indicator. Once that file disappears
> the server is stopped.
>
> How
> The idea I am working with at the moment that Kirk pointed me at was to
use the pid file in the directory as indicator. Once that file disappears
the server is stopped.
How will this work if stop server --member is invoked some a different
machine than the member that is being stopped?
-Dan
On
+1 to Bruce's comments as well.
This is exactly the kind of thing I needed to do (handle) inside of the *Spring
Test for Apache Geode* (STDG) project from a framework perspective, to
ensure that other projects relying on STDG (e.g. SBDG, SSDG) for their
integration testing purposes (e.g. client/se
The idea I am working with at the moment that Kirk pointed me at was to use the
pid file in the directory as indicator. Once that file disappears the server is
stopped.
That seems to work in my testing.
Thoughts?
Thanks,
Mark
> On Sep 11, 2019, at 10:23 AM, Dan Smith wrote:
>
> It does seem
It does seem like we should make stop synchronous, or at least make start
wait for the old process to die as Bruce suggested. Otherwise it is
difficult for someone to script the restart of a server.
Looking at the code, it does look like gfsh stop is asynchronous. There are
multiple ways to stop a
To circle back to the original test failure that prompted this discussion -
the failing test was getting intermittent bind exceptions on subsequent
server restarts.
I believe it's quite likely that a process' ports will remain unavailable
even after it is gone (I'm not sure if we create listening
Blocking or non-blocking, I don't have a strong opinion. What I'd
really like to have gfsh ensure, though, is that no-one is able to start
a new instance of a server while the old process is still around. Maybe
the PID file is the way to do that.
On 9/10/19 3:08 PM, Mark Hanson wrote:
Hello
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
@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 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
@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
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
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
`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
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
15 matches
Mail list logo
