On 21/03/18 04:49, Shawn Heisey wrote: > On 3/20/2018 9:49 PM, Phil Steitz wrote: >> First, find out what version of tomcat you are running. Then look >> in the tomcat build file sources for the properties that define the >> dbcp and pool versions being used. In TC 7, I am pretty sure the >> repackaged sources were always from release tags. Ask again if you >> have trouble locating the dbcp/pool versions once you know the TC >> version. > > Tomcat on the system I'm looking at is 7.0.42, bundled with Liferay 6.2.
Tomcat 7 uses DBCP 1.x (and always will). >> In DBCP 1.x (what TC 7 used), abandoned connection tracking was in >> the AbandonedObjectPool bundled with DBCP. Tracking can be turned >> on by configuration of BasicDataSource to remove abandoned >> connections and to log them. When connections are considered >> abandoned and closed, the stack trace of the code that created them >> is logged. That requires that they actually go past the abandoned >> connection timeout, though and get closed by the pool. > > In the pool definitions (which are in tomcat's context.xml), > removeAbandoned is true, and removeAbandonedTimeout is set to 30. (this > is really low!) But this does not appear to actually be happening. I > see connections on the server (which look like they are from the > configured pool) that have been idle for HOURS. > > Here's a relevant definition, slightly redacted: > > <Resource name="jdbc/REDACTED" auth="Container" > factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" > driverClassName="com.mysql.jdbc.Driver" type="javax.sql.DataSource" > maxActive="60" maxIdle="10" maxWait="30000" removeAbandoned="true" > removeAbandonedTimeout="30" username="REDACTED" password="REDACTED" > testOnBorrow="true" validationQuery="select 1" > url="jdbc:mysql://encore.REDACTED.com:3306/REDACTED?autoReconnect=true&zeroDateTimeBehavior=round" > /> > > The factory is different from the recommended value in the 7.0 docs > (which specifically say 7.0.85, I've got 7.0.42). Those docs say it > should be org.apache.tomcat.jdbc.pool.DataSourceFactory. I wonder if > this means that it's ignoring some of the pool configuration. org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory is the default factory and the correct factory to use for Tomcat's re-packaged version of DBCP. For the record, the code is an exact copy of the DBCP code (at the point the copy was updated). Tomcat doesn't make any local changes. Another reason for the repackaging is to prevent conflicts if an application includes its own copy of Commons DBCP. org.apache.tomcat.jdbc.pool.DataSourceFactory is the factory to use for Tomcat's JDBC pool implementation. > In a surface review of our application DB code, I have encountered a > common theme: Connections are obtained, used, and closed, all within a > try block. It is my understanding that closes should actually be done > in a finally block (with null checks), to be absolutely certain that a > close cannot be skipped, regardless of any exceptions that might occur. > I suspect that this is the root of our troubles, +1 > and that we need to > change the factory on our pool definitions. I believe not. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
