From: Samuel B. <SBucholtz@Scient.com> - 2001-05-13 06:36:47
|
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:mi...@bi...] 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 JBo...@li... http://lists.sourceforge.net/lists/listinfo/jboss-user |