commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <dirk.verbe...@pandora.be>
Subject Re: Bad deadlock on commons-dbcp 1.2.1?
Date Mon, 19 Jul 2004 17:57:41 GMT
Can you send me your pool configs?
(and other standard info like platform, OS, JVM, ...)
(the one that locks up on startup and the one with the "deadlock")

The initialSize property is only available in BasicDataSource and not 
on SharedPoolDataSource or did you add it yourself?

I don't see a deadlock in the stacktrace. There should be a "locked" 
in the DBCP somewhere... (do you keep the full trace?)

Is it possible that the SharedPoolDataSource is just slow under these 
conditions?

-- Dirk


Kevin A. Burton wrote:
> 
> I have a highly multhreaded app...We use about 300 threads which are 
> constantly using 100% of the CPU (its designed to do this to make 
> efficient use of the hardware)...
> 
> I've noticed two bugs with dbcp 1.2.1...
> 
> The first is that if you use a shallow pool with a high number of 
> threads it will lock at startup.  I've also noticed this with older 
> versions of dbcp but theres a workaround.  I just set initialSize to the 
> maxActive size of the pool.. that way all the connections are allocated 
> in a single thread.
> 
> Now I've noticed a bad deadlock after running for about 7 hours.
> 
> I did a killall -3 to get the running stacktrace.
> 
> They all seem to be locked :
> 
> org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:155)

> 
> 
> Which is:
> 
> 152:    protected synchronized PooledConnectionAndInfo
> 153:        getPooledConnectionAndInfo(String username, String password)
> 154:        throws SQLException {
> 155:        if (pool == null) {
> 156:            try {
> 157:                registerPool(username, password);
> 158:            } catch (NamingException e) {
> 159:                throw new SQLNestedException("RegisterPool failed", e);
> 160:            }
> 161:        }
> 162:
> 163:        PooledConnectionAndInfo info = null;
> 164:        try {
> 165:            info = (PooledConnectionAndInfo) pool
> 166:                .borrowObject(getUserPassKey(username, password));
> 167:        }
> 168:        catch (Exception e) {
> 169:            throw new SQLNestedException(
> 170:                "Could not retrieve connection info from pool", e);
> 180:        }
> 181:        return info;
> 190:    }
> 
> I used a tool I wrote to remove duplicate stack traces to see if there 
> was any obvious contention and I didn't see any:
> 
> http://www.peerfear.org/rss/permalink/2003/10/26/MiningForExceptionsInLogFiles/ 
> 
trace removed
> 
> ... any idea?
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message