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