help analyzing these threads from a stack trace

  • Thread starter Cross Eyed Admin
  • Start date
C

Cross Eyed Admin

I'm looking at a thread dump from Java HotSpot(TM) Client VM
(1.4.0-b92 mixed mode) on Solaris 8. It is from a tomcat webapp with
an apache (mod_jk) front end.

I'm having trouble understanding the differences between these three
threads.


First, I don't understand why the jsp in this thread is listed twice
or why the ThreadPool$ControlRunnable object is locked.

"Thread-233 JSP: /portal/process.jsp JSP: /portal/process.jsp" prio=5
tid=0x5d5280 nid=0x132 waiting on monitor [d4001000..d40019e8]
at java.lang.Object.wait(Native Method)
- waiting on <e0f061e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:495)
- locked <e0f061e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)


Secondly this thread below is waiting on a monitor. I understand that
to mean that it's waiting to get a monitor from some thread that
currently has it. Does this mean that the thread that has the monitor
(that this thread is waiting on) is in a syncronized method?


"Thread-214 JSP: /portal/process.jsp" prio=5 tid=0x3857c0 nid=0x117
waiting on monitor [d5801000..d58019e8]
at java.lang.Object.wait(Native Method)
- waiting on <e0592618> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:495)
- locked <e0592618> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)



This is what I would think a "normal" thread handling this jsp would
look like:

"Thread-216 JSP: /portal/process.jsp" prio=5 tid=0x75e0e0 nid=0x119
runnable [d5601000..d56019e8]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:116)
at org.apache.tomcat.modules.server.Ajp13.readN(Ajp13.java:759)
at org.apache.tomcat.modules.server.Ajp13.receive(Ajp13.java:793)
at org.apache.tomcat.modules.server.Ajp13.receiveNextRequest(Ajp13.java:284)
at org.apache.tomcat.modules.server.Ajp13Request.receiveNextRequest(Ajp13Interceptor.java:409)
at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Interceptor.java:298)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)


Any suggestions would be appreciated, especially any docs relating to
interpreting these stack traces (other than the info on java.sun.com).

thanks,

-ab
 
C

Chris Smith

Cross said:
I'm looking at a thread dump from Java HotSpot(TM) Client VM
(1.4.0-b92 mixed mode) on Solaris 8. It is from a tomcat webapp with
an apache (mod_jk) front end.

If you intend to look into the problem at such a low level (such as
asking about the name assigned to a thread, or why a thread is waiting
on a specific monitor at a specific instant), you'll need to specify the
exact version of Tomcat that you're using so we can correlate the stack
traces with source code, and details about your application (for
example, what is process.jsp, and where can we find its source?)

Even so, I doubt anyone will have the time to look into the situation
and explain it. Perhaps you should instead ask a higher-level question
about the problem you're trying to solve.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Robert Olofsson

: I'm looking at a thread dump from Java HotSpot(TM) Client VM
: (1.4.0-b92 mixed mode) on Solaris 8. It is from a tomcat webapp with
: an apache (mod_jk) front end.

: I'm having trouble understanding the differences between these three
: threads.
: First, I don't understand why the jsp in this thread is listed twice
: or why the ThreadPool$ControlRunnable object is locked.
: "Thread-233 JSP: /portal/process.jsp JSP: /portal/process.jsp" prio=5

Everything inside the quotes is the name of the thread. Why tomcat
give a strange name to a thread is not something I know. Threadgroup
name and thread name perhaps? It should not matter.

: tid=0x5d5280 nid=0x132 waiting on monitor [d4001000..d40019e8]
: at java.lang.Object.wait(Native Method)
: - waiting on <e0f061e8> (a
: org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

waiting on a monitor...

: Secondly this thread below is waiting on a monitor. I understand that
: to mean that it's waiting to get a monitor from some thread that
: currently has it. Does this mean that the thread that has the monitor
: (that this thread is waiting on) is in a syncronized method?

Well yes, hopefully, it means that. Calling stop/suspend/resume on
threads can give strange results regarding locks (=> waiting threads
to never enter and such things). I do not think that apache calls any
of thoose methods and neither should you.


: This is what I would think a "normal" thread handling this jsp would
: look like:

: "Thread-216 JSP: /portal/process.jsp" prio=5 tid=0x75e0e0 nid=0x119
: runnable [d5601000..d56019e8]
: at java.net.SocketInputStream.socketRead0(Native Method)
: at java.net.SocketInputStream.read(SocketInputStream.java:116)
: at org.apache.tomcat.modules.server.Ajp13.readN(Ajp13.java:759)

This seams like the thread that tries to read requests from
apache. This thread is trying to read data from the network and ajp is
the protocoll that tomcat talks to apache.

I am not sure why you think that this thread is a normal thread? I
would say that this looks like a special thread since there will be
only one of this, the servlet/jsp handlers will be many (many = more
normal).

: Any suggestions would be appreciated, especially any docs relating to
: interpreting these stack traces (other than the info on java.sun.com).

Write yourself a java profiler, read the jvmpi specification, read the
jpda specification. Use a profiler that can show some graphics that is
easier to understand.

/robo
 
C

Cross Eyed Admin

The dump is from tomcat 3.3.1a but the process.jsp is propritary code.
I'd like to post it but can't, sorry :(

I really don't want anyone else to solve the problem, I just would
like to know more info on these traces. The articles at java.sun.com
are nice, but (seem) a little outdated. For example the articles
describe the currently executing thread (at time of dump) being marked
with *current thread*, but this does not seem to be the case.

anyway thanks for your help,

-ab


John C. Bollinger said:
Cross said:
I'm looking at a thread dump from Java HotSpot(TM) Client VM
(1.4.0-b92 mixed mode) on Solaris 8. It is from a tomcat webapp with
an apache (mod_jk) front end.

I'm having trouble understanding the differences between these three
threads.

Read Chris Smith's response first. Then see below for a few brief
explanations, comments, and wild guesses.
First, I don't understand why the jsp in this thread is listed twice
or why the ThreadPool$ControlRunnable object is locked.

"Thread-233 JSP: /portal/process.jsp JSP: /portal/process.jsp" prio=5
tid=0x5d5280 nid=0x132 waiting on monitor [d4001000..d40019e8]
at java.lang.Object.wait(Native Method)
- waiting on <e0f061e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:495)
- locked <e0f061e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)

I don't know why the JSP is listed twice, but my guess is that it has
done one of the following things: (1) forwarded to itself, (2) included
itself, or (3) invoked a method on itself.

As for the ThreadPool$ControlRunnable, I speculate that it defines the
logic for doling out tasks to the Threads in its ThreadPool. Chances
are that it is necessary to synchronize on the object in order to submit
a task to the ThreadPool or for one of the Threads to take a task, and
possibly also when a Thread is done with a task.
Secondly this thread below is waiting on a monitor. I understand that
to mean that it's waiting to get a monitor from some thread that
currently has it. Does this mean that the thread that has the monitor
(that this thread is waiting on) is in a syncronized method?

[...]

The thread that owns the object's monitor owns it _because_ it is
currently executing a synchronized method of that object or a block
anywhere in the code base that is synchronized on that object. (And the
thread is not currently wait()ing.)


HTH,

John Bollinger
(e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top