---------------------------------------------------------------------------
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server
---------------------------------------------------------------------------
----- Original Message -----
From: "Peter Bauer" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Wednesday, October 17, 2007 10:52 AM
Subject: All threads are currently busy
Hi all,
System:
Tomcat 4.1.30 on Debian sarge
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
in situations with high load, tomcat sometimes stops responding and is not
able to recover from that status. In the catalina.out file, i get the
following line:
SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads
(75) or check the servlet status
i searched some time in various forums and mailing list archives and found
the following links:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200408.mbox/[EMAIL
PROTECTED]
http://marc.info/?l=tomcat-user&m=113297294417902&w=2
http://www.tek-tips.com/viewthread.cfm?qid=862552&page=3
http://www.mail-archive.com/[EMAIL PROTECTED]/msg127833.html
Basically there seem to be 2 possible reasons for this behaviour
1. A bug (?) in Tomcat or the combination of JDK, glibc, whatever, which
causes that tomcat does not
recover from situations with too much requests. I could not find any
information in the release notes
of the Tomcat 4.1.x versions.
2. Some kind of deadlock or resource (database connections) availability
problem which
keeps the request handling threads from returning from the doPost/Get
method.
So i made a Threaddump using jstack (attached file). Most of the threads
are in
- java.lang.Object.wait(long) @bci=0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, line=474 (Interpreted frame)
- org.apache.catalina.core.StandardWrapper.allocate() @bci=223, line=704
(Interpreted frame)
but 19 threads are blocked in the bci 0 of the same static synchronized
method called removeActiveRoles
which is called from the doPost() method.
-
at.sonorys.dmc.utilities.ActiveRoleRemoval.removeActiveRoles(at.sonorys.dmc.utilities.DatabaseAccess,
java.lang.String, java.lang.String, boolean) @bci=0 (Interpreted frame)
- at.sonorys.dmc.CommDicora.CommHandleMessageSession.quitSession() @bci=23
(Interpreted frame)
- at.sonorys.dmc.CommDicora.CommHandleMessageSession.doHandleSessionMsg()
@bci=131 (Interpreted frame)
- at.sonorys.dmc.CommDicora.CommHandleMessageSession.evalMessage() @bci=1
(Interpreted frame)
-
at.sonorys.dmc.CommDicora.CommDicoraServlet.doHandleMsg(javax.servlet.http.HttpServletResponse,
javax.servlet.http.HttpServletRequest) @bci=103 (Interpreted frame)
-
at.sonorys.dmc.CommDicora.CommDicoraServlet.doPost(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse) @bci=142 (Interpreted frame)
The servlet implements the SingleThreadModel (not my decision). As you can
see from the threaddump, all 19 threads are waiting to
get into the same static synchronized method. I dont understand this
because there must be one thread IN the method
which holds the lock of the method? Is it possible for a thread to leave a
synchronized method without returning the
lock?
I'm guessing here, never used SingleThreadModel..... but I think that what
may be happening is the TC for efficiency reasons is creating multiple
instances of the servlet.... otherwise imagine how slow things would be.
So its making (MAYBE) 19 instances of the servlet instance and giving each
one its own thread.... so its *still* doing what it promised (1 thread per
servlet)
BUT... unfortunately for you threads all JOIN again at a STATIC class....
So if ONE thread gets stuck in ......
static synchronized method called removeActiveRoles
they ALL do.
SingleThreadModel does not fix all threading issues.
Maybe time to just make the app thread safe and throw SingleThreadModel
away....
From the loooks of things, threads never come out of *removeActiveRoles*
alive ;)
br,
Peter
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]