On 11/15/17 12:50 PM, Shawn Heisey wrote: > I'm using DBCP 2.1.1 with POOL 2.4.3 (which are the latest releases as > of a few minutes ago) to handle connections to MySQL databases. In my > program I have code like this: > > conn = ds.getConnection(); > conn.clearWarnings(); > if (conn.isValid(5)) > > Recently, I've been having problems where the connection is showing up > as *not* valid, and I couldn't figure out why. My code uses > conn.getWarnings() on invalid connections to try and determine why the > connection is invalid, but it wasn't getting anything. No exception was > being logged, so the return was likely null. The validation query is > "SELECT 1". > > After scratching my head for a while, I decided to have the code run a > "SELECT 1" query on the connection that reports invalid. As expected > because the connection tests as invalid, that query failed, but the > specific failure was surprising: > > Caused by: > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No > operations allowed after connection closed. > > How can a connection that I *just* retrieved from the pool be closed?
Should not happen. In most cases like this, it turns out not to be the pool that closed the connection. The most common causes of this are network connectivity problems or the server closing the connection due to idle timeout. The latter seems unlikely given that you have idle eviction configured. Is it possible that some clients are holding connections for a very long time without using them? The evictor only acts on connections that are idle in the pool (i.e. it does not do anything to connections that are checked out to clients). > d > > The only thing that comes to mind is that I have configured idle > connection eviction: > > opMaster.setTimeBetweenEvictionRunsMillis(Const.ONE_MINUTE); > opMaster.setMinEvictableIdleTimeMillis(Const.ONE_MINUTE * 5); > > If the idle connection eviction is what's to blame for this (connection > becomes invalid between the time it is retrieved and the validity is > checked), it seems like that shouldn't be possible. That should not be possible, as once a connection has been checked out, it is not eligible for eviction. And even if it were evicted by the pool, the pool would set the DelegatingConnection's closed property to true so isValid would return false rather than throwing. It looks like the situation here is that the pool thinks the connection is open, but the underlying physical connection has been closed. It would be good to see your full pool config and a stack trace of the exception above. You might also look at the server logs to see what is happening on the Mysql side. Phil > > Before I open an issue in Jira, I would like to know if there's anything > I can add to my code (logging, info retrieval, etc) to check what might > be going wrong -- try to confirm my theory that idle connection eviction > is to blame. If that is indeed the problem, I would comment that > getConnection() on the datasource should probably reset the idle timer > so that the connection will not be quickly closed/pruned. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
