On 3/20/18 7:21 PM, Shawn Heisey wrote: > I've written before, trying to track down problems with our > database server getting too many connections. > > Based on what I can see of how my programs (using dbcp2) are > working, everything seems to be fine there. I've added logging to > tell me how many idle and active connections there are in the > pool, and those numbers stay low. > > So now I need to track down what's happening in our webapps, most > of which are Liferay-based, and all of which are running in > Tomcat. And I've learned that they're using the Tomcat > implementation of dbcp for database access. I think it's Tomcat > version 7, but I will need to check to make sure. > > I've figured out how to log the number of active and idle > connections, by casting the DataSource to the tomcat dbcp object > actually in use. Once I can get the developers to actually update > a production system with that code, I will be able to see whether > (as I suspect) the "active" count in the pool is staying > abnormally high. I'm betting that there's somewhere in the webapp > code that a connection is retrieved from the pool, used for some > work, and never closed. > > I have a main question, and then a semi-related but very different > question. > > Main Question: Does dbcp by chance record a stacktrace of the > code that requests a connection from the pool? I would like to > poke my way through the active connections (entry point being the > DataSource implementation), and ask them where in our code they > were requested. I have to do this in the Tomcat fork of dbcp, and > I know I'm not on a Tomcat mailing list, but I'm hoping that > whatever you can tell me will apply to that version too. 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.
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. > If I can get a stacktrace of where each connection was requested, > I can pinpoint problematic code a lot faster. There is a LOT of > code that uses the database, scattered across a lot of git > repositories. If I could grep the code easily to find them all, I > would. > > Side question: Why has Tomcat maintained what looks like a fork of > dbcp for such a long time period? If they really believe their > implementation has an advantage, it seems like everyone would > benefit if they worked to get the upstream library to offer the > same advantages. Am I drifting into flamewar territory by even > wondering about this? I did find the tomcat documentation page > about their connection pool. It basically reads to me as "Commons > DBCP is substandard and bloated. These are the many ways that our > implementation is better." There are two different things going on here. The first is the repackaged DBCP sources that tomcat ships as the default connection pool. That is not really a fork - just repackaging. In the early days of TC8, DBCP was not releasing fast enough, so IIRC a few TC releases shipped pre-release DBCP sources, but there was never really any forking going on. The second thing is the tomcat's "jdbc-pool" module that is an alternative to DBCP. The content on the web page you reference is obsolete and probably should be fixed. It refers back to 1.x versions of DBCP that used 1.x versions of pool. Those were in fact slow and buggy. The 2.x versions of DBCP have comparable performance (slightly slower, but not much) to jdbc-pool (mostly because pool 2.x is much faster). Depending on which version of TC 7 you are running, jdbc-pool for that version might be materially faster than DBCP version shipped with it. Phil > > https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html > > I haven't compared DBCP with other pool implementations, but my > work with DBCP has never run into any problems that weren't my own > fault. This mailing list has shown a high degree of patience with > my dumb questions. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
