On 05.12.2018 16:54, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Guido,
On 12/5/18 10:46, Jäkel, Guido wrote:
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 ?
In no other way than a Tomcat worker get informed about a Tomcat
shutdown if you trigger this event e.g. by the shutdown port
mechanism or JXM. OT a feature of Tomcat is that it will first
stop accepting new requests by the connectors and let the servlet
containers stop the applications afterwards. Therefore, a started
request will be finished. And after all request workers are idle,
the worker pool will terminate.
If you send a signal to a process, nothing is "interrupted" but
just a consumer in the process get signaled - that's why it's
called this way. And that's the reason why a process might not stop
if you send a SIGTERM to it. It's just a request to please the
process to terminate by itself. Some signals are handled outside
the process, for simplification let's say by the process scheduler.
If one send a SIGKILL, the scheduler will "hard kill" the process
(and it's threads) at any point of execution path and just recover
the reserved resources.
This is exactly correct.
It's often surprising to people when they find out that a SIGTERM can
initiate a "graceful" shutdown of a running JVM. I think most people
thing that SIGTERM and SIGKILL are roughly the same thing.
It's an instructive thought-experiment to consider that most
*NIX-style init systems send SIGTERM signals to all process as they
are shutting-down the operating system. This doesn't "terminate" the
processes (as the signal name might suggest), but rather "requests
that they self-terminate" where the process gets to decide how to shut
itself down.
It's only SIGKILL (or some of the hardware-generated signals like
SIGBUS) that will simply end a process without any notification or
anything else.
- -chris
Yes to both, but.
I stand contradicted in my doubt that a signal to the JVM would result in a "graceful"
tomcat shutdown. But that seems to be the case.
But Mark provided the real reason why that is so : tomcat registers a "hook" in the JVM,
so that it is notified that the JVM is shutting down. And presumably, the JVM waits for
tomcat to acknowledge, before really shutting down.
From the point of view of the OS, the only "process" is the JVM. Tomcat is not actually a
process, it is just a series of Java pre-compiled instructions being run by the JVM.
It was clear to me that the JVM actually gets signalled, and that it will, as a result,
shut down (= stop running Java code, and exit) (in its own time, unless the signal is KILL).
What was not clear to me is if the JVM in turn "signals" tomcat, or just stops running
tomcat's code immediately.
Mark clarified that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
