tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: JK and IIS - troubles?
Date Fri, 10 Oct 2008 16:53:33 GMT
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message