Summary: | Database failure may cause pool to hang | ||
---|---|---|---|
Product: | Tomcat Modules | Reporter: | Filip Hanik <fhanik> |
Component: | jdbc-pool | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | alex-pub.apache-ant, asafonov, ferrisn, monteslu |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: |
Test demonstrating jdbc-pool connection leakage
Unit test demonstrating fair queue not working properly |
Description
Filip Hanik
2012-06-06 01:01:10 UTC
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. *** |