Yes, you are quite right. However, we are, as you say stuck with whatever
implementation is made
by the JVM. Other than wrapping some native C code to handle signals and
then communicate them to
the java threads using some means, like sockets, there is nothing that can
be done.
It seems simple enough to test this on whatever implementation you happen to
be on. Write a small
program that spawns some threads, kill -TERM pid one of the threads and see
what happens. Most
likely you will have to do this for every VM and OS you routinely use.
I know that we here have scripts that kill iPlanet threads automatically to
keep the app server from dying,
I do not know if these scripts are sending TERMs or KILLs though. This of
course might work on a
website where the only thing that is lost when the thread is killed is the
request, it would not if there
are interdependencies between threads.
Samuel
-----Original Message-----
From: Michael Bilow [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 13, 2001 13:36
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] jBoss architecture question
No, no... I agree that, in the abstract, it makes sense to send the TERM
signal only to the initial or master thread. Furthermore, I entirely
agree with you that it might be appropriate for a thread to ignore TERM if
the necessary shut down processing is handled by the master thread.
There is no way, at least on Linux, to distinguish processes and threads
from userland. A thread has a process ID (pid) and runs on the system
scheduler just like any other process. The distinction between a process
and a thread in Linux is made in terms of kernel memory mapping during
task switching, since the defining characteristic of a thread is that it
shares the complete memory descriptor table of all other fellow threads.
The end result is that threads show up on the process list because they
have pids and they are therefore subject to being sent signals. This is
absolutely unavoidable in a Linux environment. Therefore, there must be
some facility in each thread to handle signals when they are sent. If the
proper behavior is for threads to ignore TERM signals, then they must
install handlers to do so. If the threads should ignore signals and they
do not, then the application is, in fact, unstable.
If the JVM can be depended up to sort this out and call the signal handler
in the master thread even when the signal is actually sent by the system
to the child thread, then that is a solution. However, I do not know
enough about the internals of any JVM to be sure that this is the case,
and I doubt that such behavior is guaranteed to occur on every JVM even if
it does occur on some JVMs. The Sun and IBM JVMs might do exactly
opposite things in this regard, although I have no idea what they do.
This discussion arose because, in the quoted post to the list, danch said
that it was a bad thing to send TERM to child threads and that TERM should
should only be sent to the master thread. So the issue for me is what
happens if TERM is sent to all of the threads instead of just the master
thread? Are the TERM signals sent to the child threads ignored, which
would be fine? Are the TERM signals sent to the child threads reflected
by the JVM to the master thread, which would also be fine? Or do the TERM
signals sent to the child threads pass through unhandled and kill those
threads abruptly, which presumably would NOT be fine?
-- Mike
On 2001-05-13 at 02:35 -0400, Samuel Bucholtz wrote:
> This is not 100% true. On Unix any process should expect to receive and
> handle a TERM signal.
> Threads on the other hand do not need to and should not be expected to
> handle a TERM. Remember, threads only act and look
> like processes when using native threads as opposed to pure java threads.
> The threads, logically, must act the same and
> be as similar as possible whether Native or Pure. Since pure threads run
> within the JVM process and will never see or
> handle a signal, there is no reason to expect the native threads to do so
> either.
> Rather, in the case of some kind of impending shutdown, etc. the signal
> should reach the master process which spawned
> (and therefore controls) the threads. It is that processes responsibility
to
> gracefully stop the threads, flush buffers,
> sync files, etc.
> A thread does not control its resources, scheduling, etc. It may or may
not
> even be able to communicate with it's
> scheduler/parent. There is no way to expect it to be able to receive a
TERM
> and know how to handle it in a graceful manner.
> As long as the parent can control/stop threads, and do the proper thing
when
> it received a signal, there is no reason to consider the application
> unstable, just because the threads ignore signals.
>
> Samuel
>
> -----Original Message-----
> From: Michael Bilow [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 2:10
> To: List: jBoss users
> Subject: Re: [JBoss-user] jBoss architecture question
>
>
> On 2001-05-11 at 22:09 -0500, danch wrote:
>
> > Jim Archer wrote:
> * * *
> > > All the threads also raise a shutdown question. We have written an
> > > init.d script to gracefully start and stop jBoss as a server task, in
> > > the same manner as other Debian processes. If the script issues a kill
> > > to each thread, will this produce a gracefull shutdown, or will it
> > > terminate each thread ungracefully?
> > >
> >
> > The kill should be sent to the parent of all the threads. If you look at
> > ps -axf output you'll see that run.sh spawns one process, which is then
> > the parent for all the threads. A change in run.sh to save the pid of
> > the java process into a file in var would be the best way to accomplish
> > this.
>
> I have a concern about this. On Unix, any process/thread should expect to
> receive a TERM signal and is obligated to handle it appropriately. If the
> process/thread elects not to install a handler to catch the TERM signal,
> then the default is for the system to kill the process abruptly, which is
> usually inappropriate for anything except the most trivial programs.
>
> It is not possible on Unix to guarantee that the graceful shutdown script
> will always be followed so that the right signals are sent to the right
> recipient processes/threads. In the case of a power failure notification
> from a UPS daemon or an emergency shutdown initiated by the watchdog
> daemon, a TERM signal will be sent directly to every process/thread. The
> process/thread TERM handler should then do whatever is necessary to close
> files, commit data, notify network partners, and otherwise assure at least
> a stable shutdown if not a graceful one.
>
> If a process/thread elects to catch TERM and do something in response,
> then it had better do it fairly quickly because, if time runs out, then
> the system can be expected to send the uncatchable KILL signal and then
> the process/thread is guaranteed to go down hard. Really bad things can
> then happen, such as the filesystem being closed with process/thread data
> uncommitted to disk.
>
> For a process/thread to be considered stable on Unix, it _must_ catch and
> handle the TERM signal intelligently if failing to do so would lead to
> data corruption or other instability. This means that it should be safe
> for every thread in jBoss, whatever it may be doing, to be sent TERM
> asynchronously in indeterminate order, and it must also be safe for any of
> these threads to be sent TERM more than once.
>
> -- Mike
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
