tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric B." <>
Subject Re: dbcp pool freezing
Date Wed, 04 Feb 2009 19:31:08 GMT
"Christopher Schultz" <> wrote in message
> Hash: SHA1
> Eric,
> Eric B. wrote:
>> I'm happy to test out an validate that theory, but based on what I've 
>> seen
>> so far, this isn't the case at all.
> Try deploying nothing in your application but the following JSP. Browse
> to it, and intentionally leak a connection. Watch your catalina.out file
> to see if an error message occurs ~20 seconds later. If you see such
> messages, Chuck's suggestion that you have some runaway looping code are
> probably something to look into.

Thanks for the pointers.  After a bit more troubleshooting, I finally got 
the abandoned connection tracking to work, and indeed managed to find a 
connection leak in a very obscure place (not in a loop).  However, during 
this process I noticed the following:

The abandoned connection tracking only seems to fire when requesting a new 
connection.  It is not a seperate background thread that cleans up abandoned 
connections.  Consequently, if all connections are being legitimately used 
when a new one is requested, the new one will go into a wait state.  Once a 
legit connection is closed, the thread waiting for a connection will be able 
to continue processing.

However, if all the connection pool is maxed out with leak'ed connections 
that have not exceeded the abandonedTimeout, the thread requesting a new 
connection will go into a wait state and wait perpetually until a second new 
thread tries to access a connection and triggers the abandoned connection 

I realize that the abandoned connection tracking is not something that a 
good app should rely upon, however, it is definitely a useful feature to 
have to ensure that your app doesn't crap out.   However, it is a little 
misleading in the belief that abandoned connections will automatically be 
returned to the pool automatically rather than only be returned once a new 
connection is requested.

Has there ever been any thought to doing abandoned connection tracking as a 
background thread, or was the current implementation decided upon to save on 



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message