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.
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.
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, and that we need to
change the factory on our pool definitions.
Thank you to both people who have replied to this thread so far.
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
