tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: jvm thread dump
Date Tue, 10 Oct 2006 16:47:10 GMT
Riz,

> Actually, we had a bit of a situation yesterday, it seems the threads
> were all locked up and/or the db connection pool was not handing out
> connections. I am not sure what happened and have been monitoring the
> threads ever since.

Well, there's yer problem ;)

> Below are some threads from the dump when the above problem happened. I
> have no idea what caused the problem, I do know that the mail server I
> was trying to connect to was flaky, that would explain thread
> "http-443-Processor75" but I have no clue why the dbcp connection
> pooling failed.

Hmm, let's take a look.

> "http-443-Processor75" daemon prio=1 tid=0x09fbc620 nid=0x330a runnable
> [0x07d76000..0x07d790c0]
>    at java.net.SocketInputStream.socketRead0(Native Method)
>    at java.net.SocketInputStream.read(SocketInputStream.java:129)
>    at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:79)
>    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
>    - locked <0x5cd7e218> (a java.io.BufferedInputStream)
>    at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:57)
>    at
> com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1327)

That looks like a perfectly reasonable thread dump. The thread is
runnable (i.e. not waiting for a lock) and in the method you expected
(something to do with SMTP). I don't see a problem, unless you observed
that particular thread taking forever or something like that.

For servlets that send email even semi-frequently, I usually recommend
dropping the email into a queue and having another thread do all of the
email sending. That frees your request processors up for actually
handling requests, and the response can go back to the user faster. Now,
if it's important that the email gets sent before the response does,
then you've gotta do what you are already doing.

Some of your threads look like this:

> "http-443-Processor74" daemon prio=1 tid=0x09fbb720 nid=0x3309 in
> Object.wait() [0x07cf7000..0x07cf8040]
>    at java.lang.Object.wait(Native Method)
>    - waiting on <0x55ed65c0> (a
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

They are all idle, waiting for requests.

Then you have the DBCP-blocking ones:
> "http-443-Processor73" daemon prio=1 tid=0xb2ac23d0 nid=0x3308 in
> Object.wait() [0x07b96000..0x07b97fc0]
>    at java.lang.Object.wait(Native Method)
>    at java.lang.Object.wait(Object.java:474)
>    at org.apache.commons.pool.impl.GenericObjectPool.borrowObject

This thread is waiting for a JDBC connection. There's nothing
particularly wrong with that, either. If you have a limited DBCP pool
size, and lots of connections, then your requests are simply going to
have to wait.

What behavior did you observe? Did all your clients time out? Did your
site get really slow? What are your request processor and DBCP settings?

> Chris, are you familiar with Spring at all? Would you be able to answer
> a few questions for me on this subject (we can take the topic offline as
> it is not relevant here).

I have never used Spring, but I am familiar with app frameworks in general.

-chris


Mime
View raw message