br1 wrote:
Apologies,
This one is much better, netstat shows 50 connections
I don't know enough of Tomcat to understand if anything in this log could
cause this issue..
Much better: You have a synchronization issue in your database
connection pool. It seems you are using the c3p0 pool, which can be
found at:
http://c3p0.cvs.sourceforge.net/
Your thread dumps (all three of them) show, that 52 threads are waiting
to get a connection from the pool:
java.lang.Object.wait(Native Method)
- waiting on <0x07c3cc50> (a com.mchange.v2.resourcepool.BasicResourcePool)
com.mchange.v2.resourcepool.BasicResourcePool.awaitAcquire(BasicResourcePool.java:968)
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:208)
- locked <0x07c3cc50> (a com.mchange.v2.resourcepool.BasicResourcePool)
com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:260)
com.mchange.v2.c3p0.PoolBackedDataSource.getConnection(PoolBackedDataSource.java:94)
com.mchange.v2.c3p0.ComboPooledDataSource.getConnection(ComboPooledDataSource.java:521)
org.theorg.thebranch.util.Sql.GetMySqlJDBCConnFromPool(Sql.java:61)
Those calls are coming from three JSPs:
Count JSP
47 jinclude.pager_jsp
3 ag_005ffigures_jsp
2 ag_005falpha_jsp
but those are not the problems. The problem seems to be either in the
pool, or the application doesn't return connections correctly to the
pool after use. The c3p0 web site has a couple of bug entries, which at
first site look related.
One Thread TP-Processor number 8 is working on some request in all three
dumps, returning content via the default servlet.
In this situation further requests would simply get stuck in the same
stack, eating up IIS threads and connections.
You can free the IIS threads by using a reply_timeout for the worker,
but you can't break the waiting for the pool inside tomcat. If you
consider using a reply_timeout, use version 1.2.26 of the redirector and
don't set the timeout to low. Also consider using max_reply_timeouts. If
the reply_timeout fires (and you got more than max_reply_timeouts of
them), then the redirector will disable the whole worker (Tomcat) for
some time. In the observed situation this is the correct way of handling
it, but you don't want to set the timeout let's say to 5 seconds and
then notice, that every now and then a Tomcat gets disabled because one
request took longer than 5 seconds. Have a look at the Timeouts docs page.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
