On 05.12.2018 11:53, Jäkel, Guido wrote:
Dear Frank,
I don't agree that this is "better". It will trigger the same things in the
backend in the end. And obviously don't need the Tomcat Connector to be available.
This might be important in situation with some malfunctions caused by near-OOM
or out-of-request-workers (caused by long running or blocked requests).
In my Tomcat farm control scripts, I also never use the "shutdown port"
mechanism to (graceful) stop the Tomcat but send a SIGTERM to the JVM. Again, this will
do the same thing
(just asking)
Does it really ? If some tomcat code is at that time processing a client POST request,
which potentially modifies data on the server (or a back-end database), is ditto tomcat
code "informed" of the JVM shutdown, and does it have time to interrupt the processing in
some predictable/recoverable way ?
but need much less to be fuctional. And if a graceful shutdown will fail, one even need
to SIGKILL the JVM.
That's another matter I believe. If a nuclear reactor was heading for meltdown, one would
push the red button, even if someone is just brewing a cup of coffee nearby.
-----Original Message-----
From: Frank Schullerer [mailto:schulle...@googlemail.com.INVALID]
Sent: Tuesday, December 04, 2018 4:06 PM
To: users@tomcat.apache.org
Subject: Re: Using tomcat manager to deploy to several services
Hello,
thanks for the answer. That is exactly the way how we do this today (all
via a shell script and via Jenkins). But I thought the
"official" way to start/stop/deploy/reload applications via e.g. "curl
http://localhost:8080/manager/text/reload?... " is better
Greetings
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
