Thread hangs, signals and JNI
Hello Blackdown developers, Abstract of this rather long message: What exactly is allowed and what is not with respect to signals in a multithreaded application that uses the Blackdown 1.2.2-RC4 JDK on Linux? I am experiencing random thread hangs inside the JVM. When that happens the entire JVM hangs, no other thread may attach to it, but the rest of the threads (that don't use the JVM) continue to run just fine. Why do I suspect that this is related to signals? Well, you'll have to read the long version below: I am developing a plug-in for AOLServer to run Tomcat in-process. For those of you who are not familiar with these two, AOLServer is a multithreaded, open source web server written in C and Tomcat is a servlet engine (written in Java). I am developing this on Linux 2.2.14 with glibc 2.1.3 and the Blackdown JDK 1.2.2-RC4. On Linux, the AOLServer use kernel threads, like the Blackdown JDK (with native threads). So far this is should be safe. The plug-in instantiates a JVM inside the AOLServer process. Threads that handle requests for servlets attach themselves to the JVM, and call a method in the servlet engine. The request is then processed on the same thread, but inside the JVM, which calls back the web server to write out the response. A request is handled this way on a single thread. ASCII drawing (WS = web server, SE = servlet engine): request --> [ C function in WS ] --> [ Java method in SE ] --> --> [ C callback in WS ] --> response All this works fine, except that in some instances the threads that process requests hang *at random points* inside the JVM. Usually a thread hangs when it calls a method (not JNI, a Java to Java call). The methods called are *not* synchronized. I know for a fact that it happens at truly random points. I have done extensive logging on the Java side using synchronous writes. There are no locks involved (synchronized blocks or methods). Also, the servlet engine (Tomcat) is just fine when it runs outside the web server. Other people that are working on a module for Apache 2.0a have encountered the same problem (but they work in a three letter company and won't ask here for help). Why do I ask about signals? Well, the really weird thing is that when I send a SIGINT to the server to shut it down, *all* threads that are blocked in the JVM suddenly awake and complete normally, sending every bit of the response to the client. AOLServer has a nice shutdown procedure that waits a while for threads to finish their work. It does however kill them if they don't finish in a given interval. Thus, I came to the conclusion that it must be related to signals. So, I started to dig this issue and I found a stern warning in the Blackdown FAQ: * Native code using JNI should NOT modify the signal processing state. The VM uses signals and any change to the signal handling may result in VM failures. Now, any decent web server (or daemon) has to intercept some signals. On the AOLServer side the source is nicely commented. The main thread does the following: /* * Block SIGHUP, SIGPIPE, SIGTERM, and SIGINT. This mask is * inherited by all subsequent threads so that only this * thread will catch the signals in the sigwait() loop below. * Unfortunately this makes it impossible to kill the * server with a signal other than SIGKILL until startup * is complete. */ I hope that you guys that wrote the Linux specific JVM can tell me if this is the reason why threads hang. If so, what should I do? Less vague questions: 1) What *exactly* is permitted and what not with respect to signals, threads and masks? You cannot reasonably expect a web server not to deal with any signals... 2) What exactly does the -Xrs flag do? How does "reduce the use of OS signals"? Can this help given the list of signals AOLServer uses? 3) What if I pass the request to a different Java-only thread in the JVM (lets call this a proxy thread) and make the C-Java thread that handles the connection wait on the C side until the proxy thread calls back the C side with the results? This would require some work so, I'd like to hear your opinion on it. Could it make any difference? The AOLServer is open source, so I can hack it any way I like, but that's not true for the JVM. Clearly a web server that wouldn't handle any signals is unlikely to be popular, so I can't just hack them out. A finer solution is needed. I have also tried the IBM 1.1.8 JDK and found the same problem. So the issue might be inherited from
Re: Thread and Garbage collection
I am assuming you are using jdk1.2 and in that case the stop method has been
depricated. You should use use Thread interrupt to stop the thread.
When you remove the Thread object from the hashtable issue a Thread.interrup()
call so the thread object unwinds correctly and exits the run method then
set the obejct reference to null so on the next GC pass the dead thread
object will be garbage collected.
Example:
class xx implements Runnable {
// class code here
void run() {
try {
while(true) {
// some code here
}
}
catch(InterruptedException e) {
e.printStackTrace();
return;
}
}
}
}
Cheers
Chris
yangyuex wrote:
Hi
I have several threads in one hashtable.
When I remove one of them, whether this thread still consume CPU etc
resources?
That's to say, if I will not need one thread, whether I must stop or
destory it explictly or
just remove it from hashtable for garbage collection?
I am not sure how JVM schedules multiple threads.
Thanks very much!
yangyuexiang
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using jdb within Emacs/JDE
Questions on JDE are more properly directed at the JDE mailing list: [EMAIL PROTECTED] There is a helpful archive of this list at http://www.mail-archive.com/[email protected]/maillist.html. Your problem stems from the fact that the jdb that is shipped with the latest 1.2 JDKs on linux is of a new architecture (based on JPDA). The 2.1.5 version of JDE does not work with this version of jdb. There are several solutions: 1. Use 'oldjdb' instead of just 'jdb'. 2. Upgrade to the latest beta release of JDE, 2.1.6. There is a new debugger in this version which is based on JPDA, and thus does not use jdb. It is not yet complete, but is rather functional. Read the 2.1.6 release notes and check out the mailing list archives for information on how to set this up - as it is still beta, there is no "formal" documentation written up on it yet. -Adam Ambrose Man Chi Ly wrote: > > my environment: > Red Hat 6.2 stock > latest blackdown JDK 1.2.2 (RC4 I believe) > GNU Emacs 20.5.1 > Emacs/JDE 2.1.5 > > The User's Guide lays out pretty clearly how to use jdb within > emacs. However, I've had no luck doing so.. I can run jdb within any shell > (including a shell within emacs) so it works; it's too tedious w/out emacs > key-bindings though. > > When I try to run the debugger, it just stalls.. here's what it looks > like: > > cd /home/mly/proj-mediator/java/ > jdb HelloWorld > > Initializing jdb... > > Deferring breakpoint HelloWorld.main. > It will be set after the class is loaded. > > run HelloWorld > > > VM Started: Set deferred breakpoint request HelloWorld:3 > > Are there any "gotchas" involved? On a different note, I've used IBM > VAJava in the past, and its debugger is credible. However, it's not an > option in my current environment. I'm wondering if JBuilder Foundation has > a strong debugger? > > TIA. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2 JNI questions
Dear Blackdown developers, I know that your time is precious, so I have only two questions regarding the interaction between a C application using Linux kernel threads and your JDK 1.2.2-RC4: 1) What *exactly* is permitted and what is not with respect to threads and signal masks? If handler is installed for signal like SIGHUP in the main thread, why do threads that block this signal hang at random points inside the JVM? 2) How does the -Xrs flag "reduce the use of OS signals"? Can you give me a list of signals that are used by your JVM with and without this flag? TIA, Vasile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread hangs, signals and JNI
Dear Ramesh, Thanks for the tips. I did make some progress, but did not solve the problem. Abstract: Sending *any* signal that is blocked by the connection threads (the only ones that attach to the JVM), but that is handled by the main thread, unblocks the JVM. Until is blocks again, obviously. Story: AOLServer does not use SIGUSR1 internally. They rely on Linux kernel threads which (AFAIK) use SIGUSR1 themselves. AOLServer does however use SIGUSR2 for an undocumented(!) purpose which I have determined to be the re-initialization of their internal TCL interpreter. A signal handler is installed, and the signal is masked for all threads other than main (which does signal handling). Fortunately, hacking out the code that used SIGUSR2 was trivial. Unfortunately it did not do the trick. I am experiencing the same problem. I am not questioning your knowledge on the SIGUSR2 issue, but note that other JVMs do not seem to use it. For instance Sun's JDK 1.2.2 for Linux does NOT use SIGUSR2. I have checked the source. Unfortunately their implementation of native threads on Linux is broken in other ways (stack corruption on pthread_join), so I cannot use it. I did notice however that sending a SIGUSR2 to the unmodified AOLServer has the same curative effect as SIGHUP. After I hacked out the SIGUSR2 code from AOLServer, sending a SIGUSR2 no longer had any effect. This tells me that SIGUSR2 *may* be part of the problem, but its definitely not all of it. This led me to generalize that sending any signal that is blocked by the connection threads, but handled in the main thread, would unblock the JVM. I tried with SIGINT and SIGTERM; just before the server goes down, the request is nicely served. The only one that doesn't do the trick is SIGPIPE. This is because the AOLServer does not install a handler for that, it only blocks it. I have tried IBM JDK 1.1.8 and the behavior is identical. Question: where do I go from here? I cannot hack out the SIGHUP or SIGINT code, it would make the AOLServer not usable as a daemon. TIA, Vasile On Wed, 17 May 2000, Ramesh Thummala wrote: > Vasile, > I had some painful experiences with the Blackdown JDK 1.2.2-RC4 with respect to >signals. It looks like Blackdown JVM is using SIGUSR1 and SIGUSR2 to suspend the JVM >threads while garbage collector starts collecting garbase. During this process, rest >of the JVM threads(exceopt garbage collector) will call a signal handler which will >wait on a semaphore until the garbage collector finishes and notifies all of them. >This is the reason why your JVM hangs at random places. When i was debugging this >problem, my JVM used to hang in a assignment statement (of all things to hang on :-( >). > If you make sure, you do not mask your SIGUSR1 and SIGUSR2, you should be able >to run fine. However, there is one caveat. Linux threads use SIGUSR1 and SIGUSR2 for >their internal communication in some products. If your product also uses them, you >should see for alternatives. > > Hope this helps, > Ramesh Thummala > > >>> Vasile GABURICI <[EMAIL PROTECTED]> 05/17/00 03:55PM >>> > Hello Blackdown developers, > > Abstract of this rather long message: > > What exactly is allowed and what is not with respect to signals in > a multithreaded application that uses the Blackdown 1.2.2-RC4 JDK on > Linux? I am experiencing random thread hangs inside the JVM. When that > happens the entire JVM hangs, no other thread may attach to it, but the > rest of the threads (that don't use the JVM) continue to run just fine. > Why do I suspect that this is related to signals? Well, you'll have to > read the long version below: > > I am developing a plug-in for AOLServer to run Tomcat in-process. > For those of you who are not familiar with these two, AOLServer is a > multithreaded, open source web server written in C and Tomcat is a servlet > engine (written in Java). > > I am developing this on Linux 2.2.14 with glibc 2.1.3 and the > Blackdown JDK 1.2.2-RC4. On Linux, the AOLServer use kernel threads, like > the Blackdown JDK (with native threads). So far this is should be safe. > > The plug-in instantiates a JVM inside the AOLServer process. > Threads that handle requests for servlets attach themselves to the JVM, > and call a method in the servlet engine. The request is then processed on > the same thread, but inside the JVM, which calls back the web server to > write out the response. A request is handled this way on a single thread. > ASCII drawing (WS = web server, SE = servlet engine): > > request --> [ C function in WS ] --> [ Java method in SE ] --> > --> [ C callback in WS ] --> response > > All this works fine, except that in some instances the threads > that process requests hang *at random points* inside the JVM. Usually a > thread hangs when it calls a meth
Re: Thread hangs, signals and JNI
>If you make sure, you do not mask your SIGUSR1 and SIGUSR2, >you should be able to run fine. However, there is one caveat. Linux >threads use SIGUSR1 and SIGUSR2 for their internal >communication in some products. If your >product also uses them, >you should see for alternatives. Actually, I believe the Linux thread support in glibc no longer uses SIGUSR1 & 2. It's more likely his problem is coming from masking all those signals (bad, bad, bad) which the JVM needs to have available to it. The AOLServer's sigwait() is essentially the source of your problems. I'm not sure how you'd fix it, as I'm not familiar with the AOLServer code. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread and Garbage collection
In a previous post I made an error in the code example
it should look like the following.
Allowing for the thread acsessing the hashtable extracting the
referenenced Thread object and calling Thread.interupt() , which BTW
sets *INTERRUPTED* flag in the Thread object,
The use of the an instance variable is redundant since the thread already has
a flag designed for that perpose.
Example :
<<< some other thread code
Thread t = htbl.get("X");
t.interrupt();
>>
class x extends Thread {
void run() {
try{
while(true){
if(interrupted()){
// do all your clean up here
return;
}
// do something else here
}
}
catch( InterruptedException e){
e.printStactTrace();
return;
}
}
Cheers
Chris
Christopher Hinds wrote:
I am assuming you are using jdk1.2 and in that case the stop method has been
depricated. You should use use Thread interrupt to stop the thread.
When you remove the Thread object from the hashtable issue a Thread.interrup()
call so the thread object unwinds correctly and exits the run method then
set the obejct reference to null so on the next GC pass the dead thread
object will be garbage collected.
Example:
class xx implements Runnable {
// class code here
void run() {
try {
while(true) {
// some code here
}
}
catch(InterruptedException e) {
e.printStackTrace();
return;
}
}
}
}
Cheers
Chris
yangyuex wrote:
Hi
I have several threads in one hashtable.
When I remove one of them, whether this thread still consume CPU etc
resources?
That's to say, if I will not need one thread, whether I must stop or
destory it explictly or
just remove it from hashtable for garbage collection?
I am not sure how JVM schedules multiple threads.
Thanks very much!
yangyuexiang
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread hangs, signals and JNI
The AOLServer code for signal handling is very simple. The
functions NsBlockSignals and NsHandleSignals are included bellow. These
functions contain all the signal handling that is relevant to this issue.
AOLServer does more funny things when it exec()s an external program, but
I am not exec()ing anythig, so the code below is all that applies.
Some notes:
- sigwait() is actually NsHandleSignals. They forgot to update the
comment at some point :-0
- NS_SIGTCL = SIGUSR2
- NS_SIGHUP = SIGHUP
- ns_sigmask = pthread_sigmask
- ns_sigwait = sigwait
The main() function first calls NsBlockSignals, then starts a
thread that will receive and dispatch connections by launching new
connection threads. After that, main() calls NsHandleSignals where it
stays until the server is shut down. Therefore, all threads that will call
the JVM will have the SIGHUP, SIGPIPE, SIGTERM, SIGINT and SIGUSR2 signals
masked.
One cannot expect a web server not to handle signals like SIGHUP
or TERM, so I don't see why this is "bad, bad, bad" in principle. The fact
that the JVM expects to run alone and handle all signals itself is IMHO
"bad, ugly, nasty" :-) I think that the AOLServer does the right thing in
protecting threads other than main from signals...
I am starting the JVM from main() between the calls to
NsBlockSignals and NsHandleSignals. That's because all modules get
initialized there. So, it should see that some signals are blocked. But I
guess that it doesn't check the mask...
Any hints from here on?
TIA,
Vasile
Code below ---
/*
*--
*
* NsBlockSignals --
*
* Block signals at startup.
*
* Results:
* None.
*
* Side effects:
* Signals will be pending until NsHandleSignals.
*
*--
*/
void
NsBlockSignals(int debug)
{
sigset_t set;
int i;
/*
* Block SIGHUP, SIGPIPE, SIGTERM, and SIGINT. This mask is
* inherited by all subsequent threads so that only this
* thread will catch the signals in the sigwait() loop below.
* Unfortunately this makes it impossible to kill the
* server with a signal other than SIGKILL until startup
* is complete.
*/
debugMode = debug;
sigemptyset(&set);
sigaddset(&set, SIGPIPE);
sigaddset(&set, SIGTERM);
sigaddset(&set, NS_SIGHUP);
sigaddset(&set, NS_SIGTCL);
if (!debugMode) {
/* NB: Don't block SIGINT in debug mode for Solaris dbx. */
sigaddset(&set, SIGINT);
}
ns_sigmask(SIG_BLOCK, &set, NULL);
}
/*
*--
*
* NsHandleSignals --
*
* Loop forever processing signals until a term signal
* is received.
*
* Results:
* None.
*
* Side effects:
* HUP and/or Tcl init callbacks may be called.
*
*--
*/
void
NsHandleSignals(void)
{
sigset_t set;
int err, sig;
/*
* Once the server is started, the initial thread will just
* endlessly wait for Unix signals, calling NsRunSignalProcs()
* or NsTclRunInits() when requested.
*/
sigemptyset(&set);
sigaddset(&set, SIGTERM);
sigaddset(&set, SIGHUP);
sigaddset(&set, NS_SIGTCL);
if (!debugMode) {
sigaddset(&set, SIGINT);
}
do {
sig = 0;
err = ns_sigwait(&set, &sig);
if (err != 0 && err != EINTR) {
Ns_Fatal("main: sigwait() error: %s", strerror(err));
} else if (sig == NS_SIGHUP) {
NsRunSignalProcs();
} else if (sig == NS_SIGTCL) {
NsTclRunInits();
}
} while (sig != SIGTERM && sig != SIGINT);
/*
* At this point the server is shutting down. First reset
* the default signal handlers so if the user is impatient
* they can send another SIGTERM and cause immediate shutdown.
*/
sigemptyset(&set);
sigaddset(&set, SIGHUP);
sigaddset(&set, SIGTERM);
if (!debugMode) {
sigaddset(&set, SIGINT);
}
ns_sigmask(SIG_UNBLOCK, &set, NULL);
}
That's it
On Wed, 17 May 2000, Christopher Smith wrote:
> >If you make sure, you do not mask your SIGUSR1 and SIGUSR2,
> >you should be able to run fine. However, there is one caveat. Linux
> >threads use SIGUSR1 and SIGUSR2 for their internal
> >communication in some products. If your >product also uses them,
> >you should see for alternatives.
>
> Actually, I believe the Linux thread support in glibc no longer uses SIGUSR1
> & 2.
>
> It's more likely his problem is coming from masking all those signals (bad,
> bad, bad) which the JVM needs to have available to it.
>
> The AOLServer's sigwait() is essentially the source of your problems. I'm
> not sure how you'd fi
Re: Thread hangs, signals and JNI
Hi Vasile, Vasile> The AOLServer code for signal handling is very simple. The Vasile> functions NsBlockSignals and NsHandleSignals are included Vasile> bellow. These functions contain all the signal handling Vasile> that is relevant to this issue. AOLServer does more funny Vasile> things when it exec()s an external program, but I am not Vasile> exec()ing anythig, so the code below is all that applies. Vasile> The main() function first calls NsBlockSignals, then Vasile> starts a thread that will receive and dispatch connections Vasile> by launching new connection threads. After that, main() Vasile> calls NsHandleSignals where it stays until the server is Vasile> shut down. Therefore, all threads that will call the JVM Vasile> will have the SIGHUP, SIGPIPE, SIGTERM, SIGINT and SIGUSR2 Vasile> signals masked. Vasile> One cannot expect a web server not to handle signals like Vasile> SIGHUP or TERM, so I don't see why this is "bad, bad, bad" Vasile> in principle. The fact that the JVM expects to run alone Vasile> and handle all signals itself is IMHO "bad, ugly, nasty" Vasile> :-) we don't say "don't use signals", we say "don't modify the signal processing state". Vasile> I think that the AOLServer does the right thing in Vasile> protecting threads other than main from signals... Vasile> I am starting the JVM from main() between the calls to Vasile> NsBlockSignals and NsHandleSignals. That's because all Vasile> modules get initialized there. So, it should see that some Vasile> signals are blocked. But I guess that it doesn't check the Vasile> mask... Vasile> Any hints from here on? Christopher is right, sigwait(3) is the problem: You create a JVM in your main thread, this automatically makes the thread a valid Java thread. Creating the JVM also starts some other threads, most notably a GC thread. I assume you also create at least one additional Java thread from the created JVM. Then you block the main thread (which also is a Java thread) with sigwait(). At some point the GC will have to take place: The GC has to suspend all Java threads, this is implemented with a signal based suspend/resume scheme (based on a bug-fixed version of Dave Butenhof's example in his 'Programming with POSIX Threads' book). But the GC fails to suspend one thread, your main thread, which is blocked in sigwait()! And that's your deadlock. If you shut down the server by sending SIGTERM, the main thread gets out of the sigwait() and the GC finally can suspend it, do its work, and then resume all Java threads. The solution is not to call sigwait() in a Java thread. In your case: Create the JVM in a separate thread and not in the primordial thread. Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 JNI questions
> Vasile GABURICI writes: Vasile> Dear Blackdown developers, Vasile> I know that your time is precious, so I have only two Vasile> questions regarding the interaction between a C Vasile> application using Linux kernel threads and your JDK Vasile> 1.2.2-RC4: Vasile> 1) What *exactly* is permitted and what is not with respect to Vasile>threads and signal masks? If handler is installed for Vasile>signal like SIGHUP in the main thread, why do threads Vasile>that block this signal hang at random points inside the Vasile>JVM? We don't use SIGHUP. Your problem is that you are blocking our suspend signal. Vasile> 2) How does the -Xrs flag "reduce the use of OS signals"? Can you Vasile>give me a list of signals that are used by your JVM Vasile>with and without this flag? The native threads implemenation uses SIGRTMIN + 3 and SIGRTMIN + 4 and SIGPIPE. The JVM also installs panic handlers for some signals and a SIGQUIT handler. If you specify '-Xrs', the JVM only installs panic handlers for SIGFPE, SIGSEGV and SIGILL. (The LinuxThreads library uses SIGRTMIN, SIGRTMIN + 1, and SIGRTMIN + 2.) Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread and Garbage collection
Thanks very much!
What's your mean:
"which BTW
sets *INTERRUPTED* flag in the Thread object,
The use of the an instance variable is redundant since the thread already
has
a flag designed for that perpose."
I also think this is a feasible way.
Because I think the root for garbage collection are implementation-dependant.
Depending on the implementation and support for native methods,
roots for garbage collection may be contained in:
o All pointers in all stack frames of the stacks of all JVM threads.
These include pointers in the local variable areas of the frames
and pointers in the operand stacks of the frames.
o All pointers to static fields of classes in the class and method
area of the JVM.
o native methods,
o registers of the JVM (for optimization)
From here, I think there is no way for the GC to collect an alive
thread although there is no reference refer to it.
So, by interrupt method here, which force run() method to finish, which
is a safe way to make the thread dead.
Christopher Hinds wrote:
In a previous post I made an error in the code example
it should look like the following.
Allowing for the thread acsessing the hashtable extracting the
referenenced Thread object and calling Thread.interupt() , which BTW
sets *INTERRUPTED* flag in the Thread object,
The use of the an instance variable is redundant since the thread already
has
a flag designed for that perpose.
Example :
<<< some other thread code
Thread t = htbl.get("X");
t.interrupt();
>>
class x extends Thread {
void run() {
try{
while(true){
if(interrupted()){
// do all your clean up here
return;
}
// do something else here
}
}
catch(
InterruptedException e){
e.printStactTrace();
return;
}
}
Cheers
Chris
Christopher Hinds wrote:
I am assuming you are using jdk1.2 and in that
case the stop method has been
depricated. You should use use Thread interrupt to stop the thread.
When you remove the Thread object from the hashtable issue a Thread.interrup()
call so the thread object unwinds correctly and exits the run method
then set the obejct reference to null so on the next GC pass the dead thread
object will be garbage collected.
Example:
class xx implements Runnable
{
// class
code here
void run()
{
try {
while(true) {
// some code here
}
}
catch(InterruptedException e) {
e.printStackTrace();
return;
}
}
}
}
Cheers
Chris
yangyuex wrote:
Hi
I have several threads in one hashtable.
When I remove one of them, whether this thread still consume CPU etc
resources?
That's to say, if I will not need one thread, whether I must stop or
destory it explictly or
just remove it from hashtable for garbage collection?
I am not sure how JVM schedules multiple threads.
Thanks very much!
yangyuexiang
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread hangs, signals and JNI
Vasile, I had some painful experiences with the Blackdown JDK 1.2.2-RC4 with respect to signals. It looks like Blackdown JVM is using SIGUSR1 and SIGUSR2 to suspend the JVM threads while garbage collector starts collecting garbase. During this process, rest of the JVM threads(exceopt garbage collector) will call a signal handler which will wait on a semaphore until the garbage collector finishes and notifies all of them. This is the reason why your JVM hangs at random places. When i was debugging this problem, my JVM used to hang in a assignment statement (of all things to hang on :-( ). If you make sure, you do not mask your SIGUSR1 and SIGUSR2, you should be able to run fine. However, there is one caveat. Linux threads use SIGUSR1 and SIGUSR2 for their internal communication in some products. If your product also uses them, you should see for alternatives. Hope this helps, Ramesh Thummala >>> Vasile GABURICI <[EMAIL PROTECTED]> 05/17/00 03:55PM >>> Hello Blackdown developers, Abstract of this rather long message: What exactly is allowed and what is not with respect to signals in a multithreaded application that uses the Blackdown 1.2.2-RC4 JDK on Linux? I am experiencing random thread hangs inside the JVM. When that happens the entire JVM hangs, no other thread may attach to it, but the rest of the threads (that don't use the JVM) continue to run just fine. Why do I suspect that this is related to signals? Well, you'll have to read the long version below: I am developing a plug-in for AOLServer to run Tomcat in-process. For those of you who are not familiar with these two, AOLServer is a multithreaded, open source web server written in C and Tomcat is a servlet engine (written in Java). I am developing this on Linux 2.2.14 with glibc 2.1.3 and the Blackdown JDK 1.2.2-RC4. On Linux, the AOLServer use kernel threads, like the Blackdown JDK (with native threads). So far this is should be safe. The plug-in instantiates a JVM inside the AOLServer process. Threads that handle requests for servlets attach themselves to the JVM, and call a method in the servlet engine. The request is then processed on the same thread, but inside the JVM, which calls back the web server to write out the response. A request is handled this way on a single thread. ASCII drawing (WS = web server, SE = servlet engine): request --> [ C function in WS ] --> [ Java method in SE ] --> --> [ C callback in WS ] --> response All this works fine, except that in some instances the threads that process requests hang *at random points* inside the JVM. Usually a thread hangs when it calls a method (not JNI, a Java to Java call). The methods called are *not* synchronized. I know for a fact that it happens at truly random points. I have done extensive logging on the Java side using synchronous writes. There are no locks involved (synchronized blocks or methods). Also, the servlet engine (Tomcat) is just fine when it runs outside the web server. Other people that are working on a module for Apache 2.0a have encountered the same problem (but they work in a three letter company and won't ask here for help). Why do I ask about signals? Well, the really weird thing is that when I send a SIGINT to the server to shut it down, *all* threads that are blocked in the JVM suddenly awake and complete normally, sending every bit of the response to the client. AOLServer has a nice shutdown procedure that waits a while for threads to finish their work. It does however kill them if they don't finish in a given interval. Thus, I came to the conclusion that it must be related to signals. So, I started to dig this issue and I found a stern warning in the Blackdown FAQ: * Native code using JNI should NOT modify the signal processing state. The VM uses signals and any change to the signal handling may result in VM failures. Now, any decent web server (or daemon) has to intercept some signals. On the AOLServer side the source is nicely commented. The main thread does the following: /* * Block SIGHUP, SIGPIPE, SIGTERM, and SIGINT. This mask is * inherited by all subsequent threads so that only this * thread will catch the signals in the sigwait() loop below. * Unfortunately this makes it impossible to kill the * server with a signal other than SIGKILL until startup * is complete. */ I hope that you guys that wrote the Linux specific JVM can tell me if this is the reason why threads hang. If so, what should I do? Less vague questions: 1) What *exactly* is permitte
