portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keshavan, Rango" <rango.kesha...@fmr.com>
Subject RE: WAS 6.1 JDBC connection leak with Jetspeed
Date Thu, 29 Nov 2007 16:34:18 GMT
Looks like the attachment didn't work.

Here's a snippet of the two methods in question.  Note,
releaseConnection doesn't do a rollback in case of an exception.  While
it's unclear if this is the root of the problem, it most certainly could
leave a connection uncommitted.


    /*
     * (non-Javadoc)
     * 
     * @see
org.apache.jetspeed.statistics.impl.BatchedStatistics#flush() should
     *      only be called from code synchronized to the linked list
     */
    public void flush()
    {
        if (logRecords.isEmpty()) return;

        Connection con = null;
        PreparedStatement stm = null;

        try
        {
            con = getConnection();
            boolean autoCommit = con.getAutoCommit();
            con.setAutoCommit(false);

            stm = getPreparedStatement(con);
            Iterator recordIterator = logRecords.iterator();
            while (recordIterator.hasNext())
            {
                LogRecord record = (LogRecord) recordIterator.next();

                loadOneRecordToStatement(stm, record);

                stm.addBatch();
            }
            int[] updateCounts = stm.executeBatch();
            con.commit();
            // only clear the records if we actually store them...
            logRecords.clear();
            con.setAutoCommit(autoCommit);
        } catch (SQLException e)
        {
            // todo log to standard Jetspeed logger
            e.printStackTrace();
        } finally
        {
            try
            {
                if (stm != null) stm.close();
            } catch (SQLException se)
            {
            }
            releaseConnection(con);
        }
    }

    void releaseConnection(Connection con)
    {
        try
        {
            if (con != null) con.close();
        } catch (SQLException e)
        {
        }
    }

------------------------------------------------
Rango Keshavan
ASTS
Internal:   8-721-4289
External:  603-721-4289
Cell:  774-258-0754


-----Original Message-----
From: Keshavan, Rango 
Sent: Thursday, November 29, 2007 11:12 AM
To: Jetspeed Developers List
Subject: RE: WAS 6.1 JDBC connection leak with Jetspeed


Raman and I did a little bit of further investigation on this issue and
found a couple things.

The code in BatchedStatistics looks like it's setting autoCommit to
false, and in the case of an exception, it's not rolling back or
committing on the connection, thus would leave the connection
uncommitted, which is an issue.

The other thing is that there is a Jira on this issue,
http://www.nabble.com/-jira--Created:-(JS2-480)-Statistics-cleanup-t9906
38.html

>From reading that, it looks like it was presumed to be fixed in the 2.1
release.  However, looking at the latest code we have, which is 2.1, I
don't see the fix.  I've attached the file.  Specifically, look at the
flush method and the releaseConnection method.

Thanks!


------------------------------------------------
Rango Keshavan
ASTS
Internal:   8-721-4289
External:  603-721-4289
Cell:  774-258-0754


-----Original Message-----
From: Tallamraju, Raman 
Sent: Thursday, November 29, 2007 10:41 AM
To: Tallamraju, Raman; Jetspeed Developers List
Subject: RE: WAS 6.1 JDBC connection leak with Jetspeed


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\
> 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>(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
> 


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


Mime
View raw message