during the con.connect(); call in the method protected PooledConnection borrowConnection(long now, PooledConnection con, String username, String password) in ConnectionPool.java There is no counting down the size of the pool. This means, if a connection failure happens here, the pool size remains the same. This means that 'size' will show the pool as full, but in reality the pool is empty
Fixed in r1346691
I don't believe this is fixed. Pulled down from svn trunk, buit, and can still easily reproduce.
I'll take a look today
Please post your configuration. Reran all tests and I'm unable to reproduce this issue.
Unable to reproduce after ticket has been reopened. Please reopen with at a minimum your configuration.
I'm able to reproduce the error on tomact 7.0.37 Exception: [http-bio-8080-exec-41] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:120; busy:119; idle:0; lastwait:30000]. Exception: [http-bio-8080-exec-33] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:120; busy:119; idle:0; lastwait:30000]. Exception: [http-bio-8080-exec-3] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:120; busy:119; idle:0; lastwait:30000].
How about Tomcat 7.0.52 -- the latest? Also, you haven't provided any indication that this is a problem with the pool... it could just be misuse of the pool. You'll need configuration, thread dumps, etc. to justify reopening this bug.
I think you may experience a different scenario here, than the actual bug reported. http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?view=markup Line throw new PoolExhaustedException("[" + Thread.currentThread().getName()+"] " + "Timeout: Pool empty. Unable to fetch a connection in " + (maxWait / 1000) + " seconds, none available[size:"+size.get() +"; busy:"+busy.size()+"; idle:"+idle.size()+"; lastwait:"+timetowait+"]."); The statement busy.size() is not just a counter, it actually measures the number of connections that are placed in the busy queue. Here is what I would do 1. set logAbandoned="true" //this will print a log entry of places in your code that are leaking connections (ie failing to call Connection.close()) With the log output from 1, we should be able to resolve all your problems.
Created attachment 31838 [details] Test demonstrating jdbc-pool connection leakage I wrote a test which demonstrates how connections can be leaked. To execute the test you need MySQL server running on port 3306.
Created attachment 31840 [details] Unit test demonstrating fair queue not working properly This tests correctly fails (assertion fails) when it is supposed to properly show the bug.
(In reply to Anton from comment #9) > Created attachment 31838 [details] > Test demonstrating jdbc-pool connection leakage > > I wrote a test which demonstrates how connections can be leaked. To execute > the test you need MySQL server running on port 3306. Anton, thank you for your test. I do confirm the bug you are seeing. Here is what I got 1. work around is to set poolProperties.setFairQueue(false) 2. I did modify the test to properly fail on assertion to demonstrate the actual bug I will get this fixed.
Great, thank you!
Fixed in trunk at r1613123
Fixed in r1613137 of Tomcat 7 branch
Flag correction in trunk r1613135
*** Bug 56660 has been marked as a duplicate of this bug. ***