Re: Bad deadlock on commons-dbcp 1.2.1?

[Dirk Verbeeck]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]