Just to clarify - I'm asking if turning off the logToDatabase parameter in statistics.xml is the right way of going about this or is there a better way?
Thanks, Raman > -----Original Message----- > From: Tallamraju, Raman > Sent: Thursday, November 29, 2007 10:25 AM > To: 'Jetspeed Developers List' > Subject: WAS 6.1 JDBC connection leak with Jetspeed > > Hi All, > > We're seeing WAS connection pool misbehave when load testing our > Jetspeed instance. WAS opens too many connections to our Oracle > database (after one test we had more that 1000 active connections even > though the connection pool max size was set to 100) sometimes bringing > down the database. On further investigation we see the following > errors repeatedly in the WAS system out logs. > > [11/27/07 2:52:48:071 EST] 00001761 MCWrapper E J2CA0081E: > Method cleanup failed while trying to execute method cleanup on > ManagedConnection WSRdbMana\ > [EMAIL PROTECTED] from resource jdbc/jetspeed. Caught > exception: com.ibm.ws.exception.WsException: DSRA0080E: An exception > was received by the Data\ > Store Adapter. See original exception message: Cannot call 'cleanup' > on a ManagedConnection while it is still in a transaction.. > at > com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataS > toreAdapterException.java:236) > at > com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataS > toreAdapterException.java:185) > at > com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(Adapt > erUtil.java:305) > at > com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransaction > s(WSRdbManagedConnectionImpl.java:3523) > at > com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanup(WSRdbManag > edConnectionImpl.java:3150) > at com.ibm.ejs.j2c.MCWrapper.cleanup(MCWrapper.java:1417) > at > com.ibm.ejs.j2c.FreePool.returnToFreePool(FreePool.java:480) > at com.ibm.ejs.j2c.PoolManager.release(PoolManager.java:1653) > at > com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:2246) > at > com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEve > ntListener.java:288) > at > com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionC > losedEvent(WSRdbManagedConnectionImpl.java:1527) > at > com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnecti > on.java:771) > at > com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:180) > at > com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:139) > at > org.apache.jetspeed.statistics.impl.BatchedStatistics.releaseConnectio > n(BatchedStatistics.java:204) > at > org.apache.jetspeed.statistics.impl.BatchedStatistics.flush(BatchedSta > tistics.java:190) > at > org.apache.jetspeed.statistics.impl.BatchedStatistics.checkAndDoFlush( > BatchedStatistics.java:86) > at > org.apache.jetspeed.statistics.impl.BatchedStatistics.run(BatchedStati > stics.java:132) > at java.lang.Thread.run(Thread.java:801) > > Looks like Jetspeed statistics is failing to release connections > because of a known issue with WAS where it isn't able to cleanup > connections when it thinks a connection is in the middle of a > transaction that hasn't committed. I've seen a ton of posts related to > this error a lot of them coming from portals & J2EE transactions in > general. Looks like WAS will be including a fix for this issue in > their 6.1.0.13 patch. > > http://www-1.ibm.com/support/docview.wss?rs=404&context=SS7K4U&dc=DB55 > 0&uid=swg1PK52881&loc=en_US&cs=UTF-8&lang=en&rss=ct404websphere > > While we wait for the patch - is there anything we can do on the > Jetspeed front to prevent this scenario from happening in the first > place? Would shutting off statistics completely fix this issue? If so, > how should I go about doing it? Not sure if this is a known issue with > BatchedStatistics class (you can see the line number in the stack > trace). > > Thanks, > Raman >
