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 Wed, 11 Oct 2006 05:05:20 GMT

I had to restart tomcat, but I am not sure if there was a simpler way to 
solve the problem at that time.
There were threads that were waiting on loading user from db (for 
authentication), which explains why I couldnt login.
I can send the thread dump (of hen the problem occurred)  tomorrow from 
work..dont have it on me right now.
The settings I sent were on production. only the https threads will make 
connections to db.

You suggested setting the debug options. We are using BasicDataSource 
from apache dbcp for pooling, and the methods to set the debug options 
you mentioned have been deprecated. Would it be ok to set these values 
Good idea to set the pool to 1 in development. Will try that.

Martin, I am using hibernate and spring to inject the datasource into 
the session factory bean. We did not set a maxActive value on the 
dataSource, but did on the hibernate properties. Any idea which value 
will be used (the default of the datasource, or the hibernate value)? 
The settings are shown below, can  you recommend ideal/better values?


    <bean id="propertyConfigurer"
        <property name="locations">

    <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.maxIdle">10</prop>           
        <property name="eventListeners">
                <entry key="merge">

Christopher Schultz wrote:
> Riz,
>> 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
>> either.
> That sounds like a wild guess at the problem. Your previous thread dump
> only included 3 threads. How many were waiting on DBCP for a JDBC
> connection? What did you have to do in order to get the server working
> again? Re-start Tomcat? Bounce the database? OR, did it clear itself up
> after a while.
> Oh, and also: was this in your production or development environment?
>>    <Connector port="8080" maxHttpHeaderSize="8192"
>>               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> Note that you have 3 connectors (HTTP, HTTPS, and AJP13) and each of
> them have a lot of potential threads in there. Your server will accept
> as many as 150 + 150 + 150 connections simultaneously. If they all need
> database connections, you're screwed, 'cause you only have between 10
> and 30 (right?):
>>                  <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>        
> I'm not sure how to set it up using hibernate's wrapper around DBCP, but
> I recommend setting the following debug options on the connection pool:
> 		<!-- Some debugging settings -->
> 		<parameter>
> 		    <name>removeAbandoned</name>
> 		    <value>true</value>
> 		</parameter>
> 		<parameter>
> 		    <name>removeAbandonedTimeout</name>
> 		    <value>300</value>
> 		</parameter>
> 		<parameter>
> 		    <name>logAbandoned</name>
> 		    <value>true</value>
> 		</parameter>
> Together, these will dump out a stack trace of any code that gets a
> database connection and never returns it. This is useful for finding
> accidental connections leaks. I also recommend setting your pol size
> fixed at 1 (yes, that's ONE) in development. It will help you find any
> connection leaks that you might have very quickly.
> -chris

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

View raw message