On 3/28/18 11:29 AM, Christopher Schultz wrote: > Phil, > > On 3/27/18 1:03 PM, Phil Steitz wrote: > > On 3/26/18 10:28 AM, Christopher Schultz wrote: > >> Shawn, > >> > >> On 3/25/18 12:17 AM, Shawn Heisey wrote: > >>> On 3/24/2018 5:04 PM, Mark Thomas wrote: > >>>> Regarding your configuration: <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://REDACTED.REDACTED.com:3306/REDACTED?autoReconnect=t > >> > >> > rue&zeroDateTimeBehavior=round" > >>>> > >>>> > >>>> > >> /> > >>>> > >>>> Generally, that looks OK but I'd strongly recommend that you > >>>> use "autoReconnect=false" in the URL. autoReconnect is known > >>>> to be problematic with connection pools. > >>>> > >>>> The removeAbandonedTimeout looks low but if all the queries > >>>> are expected to be well under 30s then that should be OK. > >> > >>> Somehow I did not see this part of your email at all when I > >>> read it the first time. I just noticed it. My previous reply > >>> probably has you scratching your head a little bit. I'm sorry > >>> about that! > >> > >>> The timeout of 30 seconds is EXTREMELY low. And if it were > >>> being honored, we would have customers lining up outside the > >>> office with pitchforks. The webapp has reporting ability for > >>> users with elevated privileges, and a lot of those reports take > >>> a minute or two to run, sometimes even longer. So if the pool > >>> were killing connections after 30 seconds, the reporting > >>> mechanism would be failing a LOT. If you check the *planned* > >>> configuration, you'll see that I have increased this timeout to > >>> 3600. I wanted to make it 900, but some of the developers are > >>> worried that 900 is too aggressive. > >> > >> The pool doesn't kill abandoned connections. It simply removes > >> them from the pool. Otherwise, you're right: you'd have torches > >> and pitchforks everywhere. > > > Not exactly, if what you are using is the DBCP pool. To see the > > 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. > > Is this DBCP, or DBCP2, or both? > > OP is running Tomcat 7.0.x. which uses DBCP(1.x)
Above references are to the 1.x versions. In 2.x, the AbandonedObjectPool was moved into Commons pool, but the behavior is basically the same - connections marked abandoned get invalidated by the pool and destroyed by the factory. Exceptions on close are swallowed with stack traces dumped to stderr. Phil > > -chris > > --------------------------------------------------------------------- > 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
