-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq73vYACgkQHPApP6U8 pFjbgBAAijzCrHGCyFPsJjZWFaD/n2bdtCJhAVXT262FFsnt2lMwXwAUqPSkyDfM 2tjsACPBL28/jrsnUI9QmaM7STa7jneqlqCsIVNcWp6YMRM3sMyk/kDcSC4zzPuG 3EkZ0gCaPLK1s8VkG9j01f7mKTp16N/xa2c1RHPktfm4458RpWqzDh84ccjt/dFU 7VVG9k3OeoJ4azfsqCBoG1tj4ker5qUctsxVoldCfB8MGpepkSfYH2Bpmd4PO8rz 3hiNhRNj3MuVLplTcA4l9mu8b9QjEWio6wljdAf66SSLdxSkE4O+aNOPBwbUvbfJ mw/udMzPaV6yhmfy3umY4TxZadpFquDv8mPqhHwcNFEPmI8f+Yb7RNEu9+LwH0Gh eultGDtkaShY/ZOOVz8OJNybKCj6bxvv3YChRm7hPk9n4OPQfTRBAxSz0a45QhmF xT/Gh6GuTtI3uMks3uCXR/4nbism+2YBZylQ0chFIsS+LNhFkhYGJ0cBQTGFoG4O uZs3ei4/JqQLttEhxEoHWtDWyFpnoQyFyoO43+k3t5OPH4FbPlWJat5voqZhlWAL B4IxtClrIl+gS3TqpAIkt/C0cNQzqUana/0RyKsKiv9UXCeMRI0v8Vzk8aYRxv1V /1GJ2RtNqj7C+2GDGpq1ePM+7zyaq52PFMFMQLzVbrTRNsjjCUo= =DivC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
