Thanks Chris.
I'll see if I can get the relevant sections from the server.xml. The
folks who have access to the server have gone home for the day.
You said:
Can you also post a thread dump? I'm surprised that Tomcat is exceeding
(or appearing to exceed) its own limit on request processing threads. I
suspect something else is going on.
*How* do you dump a thread? And, what is in it? What I am looking for
is an idea (at least) of where the app is hanging. I have little doubt
some object is getting created at some point and is not being destroyed
or is inadvertently locked by something else. Just a *hint* could get
me pointed in the right direction I think. So if I can figure out how to
dump a thread I may be able to head down the correct path. A quick
google on thread dumps in Tomcat turned up nothing that was immediately
useful.
Pete
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pete,
On 6/17/2009 8:33 AM, Pete Helgren wrote:
I am not an expert by any stretch in Tomcat internals so what I need
is a way to determine what is causing the sessions to "hang" and the
threads to begin to grow beyond the maximum (650 in our case).
Please post your <Connector> element(s) from server.xml, and any
<Executor> element(s) you may be using as well.
Can you also post a thread dump? I'm surprised that Tomcat is exceeding
(or appearing to exceed) its own limit on request processing threads. I
suspect something else is going on.
Is there a "step by step" FAQ somewhere that would allow us to
systematically analyze the running servlet and determine where the
"hang" is?
Not really. These things tend to require investigation tailored to the
app in question.
Finding the cause of hung threads can be easy if the thread dumps point
to a single thing everyone's waiting on. If not, it could take a while
to find out what's going on. Being able to reproduce this problem in a
lab environment (preferably with fewer threads, just to maintain your
own sanity during research) is essential.
Finding the cause of dead sessions will require the use of a memory
profiler or some very good guesses and luck. Are the sessions themselves
not expiring, or are objects from those expired sessions living beyond
their expected expiration date?
Are you playing any games with your HttpSession objects such as caching
them somewhere for cross-session data manipulation?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAko5NxEACgkQ9CaO5/Lv0PAJPACdFi+hNUHSszFZa6ekMGI5A3Ju
BkAAniZYPUtFWdRvVAX1MttHlqld78ZG
=DgU1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
