You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Gazda <Pa...@nau.edu> on 2010/02/10 18:46:22 UTC
DBCP 1.3 Already closed error
(Per Phil Steitz's suggestion, I am moving our off list correspondence to this list.)
Thanks, Phil. I will see what I can find re the Oracle driver.
Paul Gazda wrote:
> Our DBAs did not have any useful log info, so I am going to try putting some debugging statements in isClosed() to see if I can get any clues.
>
The isClosed() causing the problem is in the driver, not DBCP. What
is causing the problem is that the *driver* is reporting the
connection as closed when DBCP thinks the connection is open. You
might try googling isClosed and the Oracle driver. As I said, I
vaguely recall reports of the Oracle driver incorrectly reporting
closed status of JDBC connections.
> Paul Gazda
>
> -----Original Message-----
> From: Phil Steitz [mailto:phil.steitz@gmail.com]
> Sent: Wednesday, February 10, 2010 7:34 AM
> To: Paul Gazda
> Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7
>
> Paul Gazda wrote:
>> RE: Actually, if you just catch and ignore the SQLException on close,
>> this will not deplete the pool as the pool as already invalidated
>> the connection. So just enclosing your close statements in try -
>> catch - ignore blocks should resolve your problem.
>>
>> Actually I had thought of that, but the problem is there are probably a hundred close statements across several applications. That is a lot of work, and I would need to code it to only ignore the "Already closed" error, the wording of which could change in the future.
>>
>
> Unfortunately, I think the right solution for you is to find out
> what is causing the connections to get closed - or at least for
> Oracle to think they are closed - before they are returned to the
> pool. This could be causing other problems that you don't yet know
> about.
>
> I don't like the idea of having DBCP just swallow these exceptions.
>
> This discussion, btw, would be good to have on the commons-dev list.
>
> Phil
>> Paul Gazda
>>
>> -----Original Message-----
>> From: Phil Steitz [mailto:phil.steitz@gmail.com]
>> Sent: Tuesday, February 09, 2010 7:02 PM
>> To: Paul Gazda
>> Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7
>>
>> Paul Gazda wrote:
>>> Phil,
>>> Thanks for your comments.
>>>
>>> RE: Do you allow access to the underlying connection in your code and do
>>> you manipulate - and possibly close - it anywhere?
>>> Not as far as I know. I use this same pattern in many tomcat web applications without issues:
>>> DataSource ds = (DataSource)envCtx.lookup(DATASOURCE_CONTEXT_WEB);
>>> Connection dbConn = ds.getConnection();
>>> ...do db stuff
>>> dbConn.close();
>>>
>>> The error occurs on dbConn.close().
>>>
>>> RE: Is there some other process that can be closing physical connections
>>> owned by the pool? Do you see anything in the database logs?
>>> I have asked the DBAs to see if they can find anything. I'll work with them on this.
>>>
>>> Since you grabbed the code, you can see what is going on by looking
>>> at the close method in PoolableConnection. The _conn member is the
>>> underlying JDBC connection.
>>> Could a solution be to simply throw the underlying connection away if it has been closed? I know this could deplete the pool in a hurry if it happened on every close, but in that case the pool would be depleted whether errors were thrown or not.
>>>
>> Actually, if you just catch and ignore the SQLException on close,
>> this will not deplete the pool as the pool as already invalidated
>> the connection. So just enclosing your close statements in try -
>> catch - ignore blocks should resolve your problem.
>>
>> Phil
>>
>>
>>> Paul Gazda
>>>
>>> -----Original Message-----
>>> From: Phil Steitz [mailto:phil.steitz@gmail.com]
>>> Sent: Monday, February 08, 2010 6:33 PM
>>> To: Paul Gazda
>>> Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7
>>>
>>> Paul Gazda wrote:
>>>> Hello Phil.
>>>> I'm a newcomer to the dbcp package. We have been trying to stop the "Already closed" errors that occur regularly but not predictably in our uPortal 2.6.1 application. I have compiled DBCP RC6 (the latest I could find in the public repository), and we still get the error:
>>>> Caused by: java.sql.SQLException: Already closed.
>>>> at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
>>>> at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
>>>> at edu.nau.its.sia.servlets.itssServlets.dao.OutageDao.getOutagesByDate(OutageDao.java:538)
>>>>
>>>> I have found a lot of bug issues related to this general problem, and tried applying the patches in DBCP-23 DBCP233 to 1.2.2, but that also failed to solve the problem. We are using Oracle 10.2.0.4 and tomcat 5.5.27, and the error occurs when a normal connection close statement is executed: outageConn.close();
>>>>
>>>> Is this problem fixed in RC7, or could it be some other underlying problem not related to the DBCP code?
>>>>
>>>> Many thanks.
>>>>
>>>> Paul Gazda
>>>>
>>>>
>>> Hi Paul,
>>>
>>> The error message may be a little misleading, but what is going on
>>> here is that the *underlying physical connection* has been closed
>>> when an attempt is made to return the connection handle to the pool.
>>> The bugs that you mention - which were fixed in DBCP 1.3/1.4 -
>>> addressed the problem that it was not previously possible to return
>>> a connection handle to the pool twice in sequence (i.e., to execute
>>> close twice on the same connection handle).
>>>
>>> When a connection handle (PoolableConnection) is returned to the
>>> pool, the pool first checks to see if the underlying physical
>>> connection has been closed. It uses Connection.isClosed() to check
>>> that. (I vaguely recall some reports of some Oracle drivers not
>>> reporting this correctly in certain situations.) If the underlying
>>> connection has been closed, an exception is thrown, as we don't want
>>> to return a handle to a closed physical connection to the pool.
>>>
>>> Do you allow access to the underlying connection in your code and do
>>> you manipulate - and possibly close - it anywhere?
>>>
>>> Is there some other process that can be closing physical connections
>>> owned by the pool? Do you see anything in the database logs?
>>>
>>> Since you grabbed the code, you can see what is going on by looking
>>> at the close method in PoolableConnection. The _conn member is the
>>> underlying JDBC connection.
>>>
>>> Phil
>>>
>
Paul Gazda
RE: [dbcp]: DBCP 1.3 Already closed error
Posted by Paul Gazda <Pa...@nau.edu>.
I finally got to the bottom of what was happening with the "already closed" error. Because of nested try-catch-finally blocks, I was missing the ultimate cause of the error in the stack trace (lesson learned to look more thoroughly at a stack trace even if it is very, very long). I put additional debug statements in my code and found that the connection was already closed at the time that the sql statement was executed, but the error message at the top of the stack trace was from the close statement in the finally block. This most often happened when the connections sat idle in the pool over night in my test environment. It does seem to be a hardware error of some sort. I solved the problem by adding testOnBorrow="true" to the resource definition.
We are left with the mystery of why the connections are becoming invalid in the pool, but it is infrequent enough that we will just live with it for now. So, I support Phil's statement of "My inclination is to leave as is, as either the driver is bugged or something bad is going on and I would want to know about it if it were my client code."
Thanks, Phil, for all of your help on this.
Paul Gazda
-----Original Message-----
From: Phil Steitz [mailto:phil.steitz@gmail.com]
Sent: Wednesday, February 10, 2010 12:56 PM
To: Commons Developers List
Subject: [dbcp]: DBCP 1.3 Already closed error
A little more context on this. From this trace below, you can see
that what is going on is the exception is thrown by
PoolableConnection.close(), which tests _conn.isClosed() (driver
call) before returning a connection to the pool. If DBCP thinks the
connection is open - PoolableConnection.isClosed returns false - but
_conn.isClosed() returns true, then an SQLException is thrown, as
this indicates that the underlying JDBC connection was somehow
closed without DBCP knowing about it.
http://issues.apache.org/jira/browse/DBCP-193 gives s clue as to
what may be going on - Oracle 10g drivers will return true for
isClosed after a "End of File communication on CHannel" (ORA-03113)
occurs.
So the question is, do we reopen DBCP-193 and modify the code to
silently dispose of the connection when _conn.isClosed returns true,
or leave as is and force users to catch and handle this. My
inclination is to leave as is, as either the driver is bugged or
something bad is going on and I would want to know about it if it
were my client code.
Phil
>
>>>>> I'm a newcomer to the dbcp package. We have been trying to stop the "Already closed" errors that occur regularly but not predictably in our uPortal 2.6.1 application. I have compiled DBCP RC6 (the latest I could find in the public repository), and we still get the error:
>
>>>>> Caused by: java.sql.SQLException: Already closed.
>
>>>>> at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
>
>>>>> at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
>
>>>>> at edu.nau.its.sia.servlets.itssServlets.dao.OutageDao.getOutagesByDate(OutageDao.java:538)
>
>
>>>>> I have found a lot of bug issues related to this general problem, and tried applying the patches in DBCP-23 DBCP233 to 1.2.2, but that also failed to solve the problem. We are using Oracle 10.2.0.4 and tomcat 5.5.27, and the error occurs when a normal connection close statement is executed: outageConn.close();
>
>
>>>>> Is this problem fixed in RC7, or could it be some other underlying problem not related to the DBCP code?
>
>
>>>>> Many thanks.
>
>
>>>>> Paul Gazda
>
>
>
>>>> Hi Paul,
>
>
>>>> The error message may be a little misleading, but what is going on
>
>>>> here is that the *underlying physical connection* has been closed
>
>>>> when an attempt is made to return the connection handle to the pool.
>
>>>> The bugs that you mention - which were fixed in DBCP 1.3/1.4 -
>
>>>> addressed the problem that it was not previously possible to return
>
>>>> a connection handle to the pool twice in sequence (i.e., to execute
>
>>>> close twice on the same connection handle).
>
>
>>>> When a connection handle (PoolableConnection) is returned to the
>
>>>> pool, the pool first checks to see if the underlying physical
>
>>>> connection has been closed. It uses Connection.isClosed() to check
>
>>>> that. (I vaguely recall some reports of some Oracle drivers not
>
>>>> reporting this correctly in certain situations.) If the underlying
>
>>>> connection has been closed, an exception is thrown, as we don't want
>
>>>> to return a handle to a closed physical connection to the pool.
>
>
>>>> Do you allow access to the underlying connection in your code and do
>
>>>> you manipulate - and possibly close - it anywhere?
>
>
>>>> Is there some other process that can be closing physical connections
>
>>>> owned by the pool? Do you see anything in the database logs?
>
>
>>>> Since you grabbed the code, you can see what is going on by looking
>
>>>> at the close method in PoolableConnection. The _conn member is the
>
>>>> underlying JDBC connection.
>
>
>>>> Phil
>
>
>
> Paul Gazda
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[dbcp]: DBCP 1.3 Already closed error
Posted by Phil Steitz <ph...@gmail.com>.
A little more context on this. From this trace below, you can see
that what is going on is the exception is thrown by
PoolableConnection.close(), which tests _conn.isClosed() (driver
call) before returning a connection to the pool. If DBCP thinks the
connection is open - PoolableConnection.isClosed returns false - but
_conn.isClosed() returns true, then an SQLException is thrown, as
this indicates that the underlying JDBC connection was somehow
closed without DBCP knowing about it.
http://issues.apache.org/jira/browse/DBCP-193 gives s clue as to
what may be going on - Oracle 10g drivers will return true for
isClosed after a "End of File communication on CHannel" (ORA-03113)
occurs.
So the question is, do we reopen DBCP-193 and modify the code to
silently dispose of the connection when _conn.isClosed returns true,
or leave as is and force users to catch and handle this. My
inclination is to leave as is, as either the driver is bugged or
something bad is going on and I would want to know about it if it
were my client code.
Phil
>
>>>>> I'm a newcomer to the dbcp package. We have been trying to stop the "Already closed" errors that occur regularly but not predictably in our uPortal 2.6.1 application. I have compiled DBCP RC6 (the latest I could find in the public repository), and we still get the error:
>
>>>>> Caused by: java.sql.SQLException: Already closed.
>
>>>>> at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
>
>>>>> at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
>
>>>>> at edu.nau.its.sia.servlets.itssServlets.dao.OutageDao.getOutagesByDate(OutageDao.java:538)
>
>
>>>>> I have found a lot of bug issues related to this general problem, and tried applying the patches in DBCP-23 DBCP233 to 1.2.2, but that also failed to solve the problem. We are using Oracle 10.2.0.4 and tomcat 5.5.27, and the error occurs when a normal connection close statement is executed: outageConn.close();
>
>
>>>>> Is this problem fixed in RC7, or could it be some other underlying problem not related to the DBCP code?
>
>
>>>>> Many thanks.
>
>
>>>>> Paul Gazda
>
>
>
>>>> Hi Paul,
>
>
>>>> The error message may be a little misleading, but what is going on
>
>>>> here is that the *underlying physical connection* has been closed
>
>>>> when an attempt is made to return the connection handle to the pool.
>
>>>> The bugs that you mention - which were fixed in DBCP 1.3/1.4 -
>
>>>> addressed the problem that it was not previously possible to return
>
>>>> a connection handle to the pool twice in sequence (i.e., to execute
>
>>>> close twice on the same connection handle).
>
>
>>>> When a connection handle (PoolableConnection) is returned to the
>
>>>> pool, the pool first checks to see if the underlying physical
>
>>>> connection has been closed. It uses Connection.isClosed() to check
>
>>>> that. (I vaguely recall some reports of some Oracle drivers not
>
>>>> reporting this correctly in certain situations.) If the underlying
>
>>>> connection has been closed, an exception is thrown, as we don't want
>
>>>> to return a handle to a closed physical connection to the pool.
>
>
>>>> Do you allow access to the underlying connection in your code and do
>
>>>> you manipulate - and possibly close - it anywhere?
>
>
>>>> Is there some other process that can be closing physical connections
>
>>>> owned by the pool? Do you see anything in the database logs?
>
>
>>>> Since you grabbed the code, you can see what is going on by looking
>
>>>> at the close method in PoolableConnection. The _conn member is the
>
>>>> underlying JDBC connection.
>
>
>>>> Phil
>
>
>
> Paul Gazda
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org