portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tallamraju, Raman" <Raman.Tallamr...@FMR.COM>
Subject WAS 6.1 JDBC connection leak with Jetspeed
Date Thu, 29 Nov 2007 15:25:29 GMT
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\
gedConnectionImpl@22422242 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>(DataSto
reAdapterException.java:236)
        at
com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataSto
reAdapterException.java:185)
        at
com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(Adapter
Util.java:305)
        at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(
WSRdbManagedConnectionImpl.java:3523)
        at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanup(WSRdbManaged
ConnectionImpl.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(ConnectionEvent
Listener.java:288)
        at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionClo
sedEvent(WSRdbManagedConnectionImpl.java:1527)
        at
com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnection
.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.releaseConnection(
BatchedStatistics.java:204)
        at
org.apache.jetspeed.statistics.impl.BatchedStatistics.flush(BatchedStati
stics.java:190)
        at
org.apache.jetspeed.statistics.impl.BatchedStatistics.checkAndDoFlush(Ba
tchedStatistics.java:86)
        at
org.apache.jetspeed.statistics.impl.BatchedStatistics.run(BatchedStatist
ics.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=DB550&
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message