On 3/27/18 5:41 PM, Shawn Heisey wrote: > On 3/27/2018 11:03 AM, Phil Steitz wrote: >> Not exactly, if what you are using is the DBCP pool. To see the > The factory in use right now is > "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory". Information > gathered previously in this thread told me that this is DBCP code, > repackaged into the tomcat package space to avoid conflicting with the > official commons-dbcp package. If this is effectively unmodified DBCP, > then what you wrote below likely applies.
As Mark said above, based on your version of tomcat, it is exactly dbcp 1.4, pool 1.5.7. > >> details of what is going on, look at the removeAbandoned code in >> DBCP's AbandonedObjectPool. It calls >> o.a.c.pool.GenericObjectPool#invalidateObject, which calls >> o.a.c.dbco.PoolableConnectionFactory#destroyObject to close the >> connection. If an exception occurs, it is swallowed by >> removeAbandoned, but it dumps a stack trace. >> >> So connections should in fact be closed if they are detected as >> abandoned. As I said on commons-user, in your setup, that won't >> happen unless borrows are attempted when there are 57+ open >> connections. The removeAbandoned method is called *only* by >> borrowObject in DBCP 1.x, with this test: > It would not surprise me to learn that on the pool with maxActive=60, > the pool is managing less than 57 connections. Until I can get some > logging in place on production to show me the acive and idle connection > counts, I do not know what's actually happening. > > If I can successfully get a config using > "org.apache.tomcat.jdbc.pool.DataSourceFactory" operational (which seems > to be failing right now with "too many connections" on startup), is it > true that this pool does not require maxActive-3 connections before > abandoned removal kicks in? The description for > abandonWhenPercentageFull in the tomcat documentation implies that this > is the case. > > So now I have one person telling me that removeAbandoned DOES close > connections, and another saying that it does NOT close connections. Is > there a conflict here, or are both of these statements correct for > different pool implementations? Keep in mind that the current config > uses "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" Using that one, you get the dbcp / pool combo above and abandoned connection removal does try to close connections when they are marked abandoned. As I said, if the close fails, the failure should result in a stack trace written to stderr. There is a unit test in dbcp 1.4, TestAbandonedBasicDataSource#testAbandonedClose that verifies this behavior. Phil > and that I > would like to try a new config with > "org.apache.tomcat.jdbc.pool.DataSourceFactory" ... unless there is a > good reason to NOT use that factory. Which, by the way, is the factory > that tomcat's documentation SAYS to use. > > The new config with the new factory fails to start on our staging > server, but aside from seeing "too many connection" exceptions in the > catalina log, I have no concrete information about what happened. I > didn't do the restart, and wasn't watching the system when it happened. > Switching back to the old config fixed the tomcat startup. What the > developer described to me shouldn't have been possible. I need to do > the restart myself and watch the system. > > I've come up with another question, related to this, but headed in a > different direction. I'll write a new email to the list for that. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
