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
signature.asc
Description: OpenPGP digital signature
