openejb-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From grigory <grigor...@gmail.com>
Subject Re: DBCP Connection pool blocks threads on open/close connections
Date Mon, 14 Feb 2011 19:51:46 GMT

Andy, thank you for replying! 

My problem is that it's not really clear that we are experiencing connection
pool starvation here. Why would we block on RELEASING connection to the
pool? Is it a sign of such starvation? Couple of examples:


State: BLOCKED on org.apache.commons.pool.impl.GenericObjectPool@1ea6b4a
owned by: JMS Resource Adapter-worker-18
Total blocked: 31,192  Total waited: 0

Stack trace: 
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:916)
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:91)
   - locked org.apache.commons.dbcp.PoolableConnection@18a40ea
org.apache.commons.dbcp.managed.ManagedConnection.close(ManagedConnection.java:147)
com.xxxxx.DbHelper.closeConnection(DbHelper.java:290)
...
com.xxxxx.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:95)


Another example of blocked thread (in this case it's committing transaction
on EJB method):

Stack trace: 
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:916)
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:91)
   - locked org.apache.commons.dbcp.PoolableConnection@129be35
org.apache.commons.dbcp.managed.ManagedConnection.transactionComplete(ManagedConnection.java:183)
org.apache.commons.dbcp.managed.ManagedConnection$CompletionListener.afterCompletion(ManagedConnection.java:158)
org.apache.commons.dbcp.managed.TransactionContext$1.afterCompletion(TransactionContext.java:112)
org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:527)
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:326)
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245)
org.apache.openejb.core.transaction.JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:291)
org.apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:75)
org.apache.openejb.core.transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:74)
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:241)
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:174)
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:282)
$Proxy79.processOrder(Unknown Source)
com.xxxxx.OrderMessage.process(OrderMessage.java:54)
...
com.xxxxx.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:95)


We tested performance as follows:
1. There are 2 queues and 2 corresponding MDBs. 1st queue MDB is
single-threaded (MDB pool consists of 1 instance - configured using
ejb-jar.xml activation-config). Next, this MDB posts new messages (2-5
messages per invocation) to 2d queue. 2d queue is multi-threaded (default
pool contains 10 instances). 
2. Both MDBs transactional attributes are NOT_SUPPORTED. They do call
transactional EJBs (default: REQUIRED) which in turn use connection pool.
3. When we run tests in full configuration both MDBs experience blocking on
dbcp connection pool (open and close) and performance for 1st MDB is 4K
messages per hour. 
4. When we disable posting to 2d queue (effectively eliminating 2d MDB from
the picture) performance jumps 5 fold (20K messages per hour). There is
nothing serious going on inside 2 MDB to compensate for such jump in
performance except for the blocking (and CPU is at 50% in this case while
it's just 5-10% in former)
5. Note that 1st queue MDB is single-threaded, so in both cases it's
sequential processing that we measure.

We use standard JDBC cleanup to release connections (in finally). We do
request multiple connections within single transaction. Would this be a
problem?


Connection pool definition:

<Resource id="MyDataSource" type="DataSource">
  JdbcDriver oracle.jdbc.driver.OracleDriver
  JdbcUrl ${oracle.jdbc}
  UserName ${oracle.user}
  Password ${oracle.password}
  JtaManaged true
  InitialSize 5
  MaxActive 30
  ValidationQuery SELECT 1 FROM DUAL
  TestOnBorrow true
</Resource>
-- 
View this message in context: http://openejb.979440.n4.nabble.com/DBCP-Connection-pool-blocks-threads-on-open-close-connections-tp3303674p3305688.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Mime
View raw message