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.
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:
if (config != null
&& config.getRemoveAbandoned()
&& (getNumIdle() < 2)
&& (getNumActive() > getMaxActive() - 3) ) {
removeAbandoned();
}
Another thing you should do is to set logAbandoned to true so you
get a stack trace if / when abandoned connections are detected and
close.
Phil
>
> Sounds like you need to raise that timeout by a LOT.
>
> Also, set logAbandoned="true" and you'll get a helpful message every
> time a connection is considered abandoned and you'll find out if you
> have a connection leak (as opposed to simply a too-short "abandoned"
> setting).
>
> > Because there are no pitchforks, I know that abandoned connection
> > removal is NOT happening, even though it IS configured.
>
> It's probably happening, just not meeting your expectations. Those
> abandoned connections will pretty much live forever, no longer being
> managed by the pool and yet still counting as being used by the
> server. Maybe lower your idle-timeout on the server to help with this.
>
> Hope that helps,
> -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
