tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rizwan Merchant <>
Subject Re: jvm thread dump
Date Tue, 10 Oct 2006 17:06:07 GMT

Appreciate all your help.
Basically, we could not log into the system at all (which sounded like 
the app could not get a connection to the db to authenticate my user 
name and password). I had someone else try to log in, but he could not 

Here are our tomcat and dbcp settings. We are using hibernate and spring 
to configure the settings...

    <Connector port="8080" maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="443" acceptCount="100"
               connectionTimeout="20000" disableUploadTimeout="true" />

    <!-- Define a SSL HTTP/1.1 Connector on port 443 -->

    <Connector port="443" maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" 
keystoreFile="******" keystorePass="******" />

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009"
               enableLookups="false" redirectPort="443" 
protocol="AJP/1.3" />

    <!-- Define a Proxied HTTP/1.1 Connector on port 8082 -->
    <!-- See proxy documentation for more information about using this. -->
    <Connector port="8082"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" acceptCount="100" 
               proxyPort="80" disableUploadTimeout="true" />

DBCP settings using Spring's applicationContext...

    <bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" 
value="${hibernate.connection.driver_class}" />
        <property name="url" value="${hibernate.connection.url}" />
        <property name="username" 
value="${hibernate.connection.username}" />
        <property name="password" 
value="${hibernate.connection.password}" />

    <!-- Hibernate SessionFactory -->
    <bean id="sessionFactory"
        <property name="dataSource" ref="dataSource" />
        <property name="mappingDirectoryLocations">
        <property name="hibernateProperties">
                <prop key="hibernate.dialect">
                <prop key="hibernate.show_sql">false</prop>
                <prop key="hibernate.generate_statistics">true</prop>
                  <prop key="hibernate.dbcp.maxActive">30</prop>
                  <prop key="hibernate.dbcp.whenExhaustedAction">20</prop>
                 <prop key="hibernate.dbcp.maxWait">1000</prop>
                 <prop key="hibernate.dbcp.maxIdle">10</prop>           
        <property name="eventListeners">
                <entry key="merge">

Christopher Schultz wrote:
> 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 Method)
>>    at
>>    at
>>    at
>>    at
>>    - locked <0x5cd7e218> (a
>>    at com.sun.mail.util.LineInputStream.readLine(
>>    at
>> com.sun.mail.smtp.SMTPTransport.readServerResponse(
> 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(
>>    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

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message