Marko wrote: > In that case debugging looks like the only option?
Nobody yet disputed: > The 'leakiness' of the pool is actually in > org.apache.tomcat.jdbc.pool.FairBlockingQueue#poll() > If the line (!c.await(timeout, unit)) exits via an > InterruptedException, the the 'exchangecountdownlatch' is never > removed from the waitlist ... connections will be 'exchanged' with > threads which will never rendezvous. To labour the point: On line 650 of http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?view=markup there is a call to 'idle.poll()'. 'idle' is a FairBlockingQueue (assigned in 448). On lines 150 to 155 of FairBlockingQueue http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java?revision=1432842&view=markup, the poll(long,TimeUnit) method **does not invoke waiters.remove(c) if line 150 throws InterruptedException**. That's a bug that explains the 'bleed'. Eventutally, a connection is offered to the queue, The pool selects a 'waiter' to give the connection to, but the thread supposedly awaiting on the latch is dead. The connection escapes from pool, and is never put back. I offered a workaround: > But why is InterruptedException being thrown anyway? That'll be > because the Tomcat worker thread trying to acquire a connection > gets issued aWorkerThread.interrupt() for taking too long. So > adjusting some timeout settings (to make Tomcat more patient > than the connection pool) should give a workaround. DBCP had > a better grasp of what was going on when reporting this. Or I guess, there could be some other fault that's calling interrupt() on the thread, but a timeout from the container (which owns the thread) is the most likely option. cheers, David. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
