Jerry,
On 12/7/21 20:59, Jerry Malcolm wrote:
Chris, The way I thought it worked was if I configured
'RemoveAbandonedOnBorrow' and RemoveAbandonedTimeout="15" was that each
time I requested a new connection from the pool, any connections that
had been idle for >15 minutes and had not been returned by my code to
the pool would be recovered, returned to the pool and logged (assuming
logAbandoned was set).
Nope. "removeAbandoned" causes any connection that isn't returned to the
pool to be *removed from the pool*, and replaced with a new (presumably
working) connection. The connection that was never returned ... stays
out there, doing whatever it was doing.
"logAbandoned" just lets you know when the pool gives up. It doesn't
"do" anything (other than the logging).
The alternative would be for the pool to forcibly terminate the
connection, which could cause all kinds of chaos, so it does the only
thing it can reasonably do: forget the connection ever existed in the
first place. If your code never closes it, and the Connection object
never gets GC'd (and, presumably, closed in the process), then it just
lived forever, wasting an open-connection to your db. Since you have
limited your total connections (per user? per host?) you eventually run
out due to the leak.
Until a few days ago I had a code error that was bypassing the closing
of the connection in certain situations, and after 12-24 hours the pool
had worked its way up to maxing out. My problem is fixed now, and the
numActive count is staying fairly flat during normal activity. But the
way I understood removeAbandonedOnBorrow was that TC connection pooling
code would not allow errant connections to remain in use forever.
I'm sure I'm just misunderstanding how it works. Again, not critical at
this moment. But I'd like to figure out where my understanding is wrong
for future situations.
You thought the pool would "clean-up" the mess. IT doesn't. What it
*does* do is allow the pool to continue to function and provide its
service to the application, even when the application is leaking
connections.
So, rather than starving clients when connections leak, those
connections are simply allowed to leak.
I always recommend running with maxActive="1" in development, with
removeAbandoned="false" and logAbandoned="true". You'll find any leaks
VERY quickly. ;)
-chris
On 12/7/2021 2:31 PM, Christopher Schultz wrote:
Jerry,
On 12/4/21 23:06, Jerry Malcolm wrote:
I had a db connection leak in my code where an error condition would
throw an exception and bypass the connection cleanup code. I found
that and fixed it. But before I found the problem, my program was
overrunning the max connections and locking out. It would take
sometimes 12 hours after a reboot to go from 0 connections to max.
Normal steady state connections should currently be under 50. The
ramp over several hours to max was very obvious in my numActive log.
What I'm confused about is why removeAbandoned didn't recover those
connections.
When you say "recover"... what exactly do you mean?
Granted, if I write my code correctly, removeAbandoned shouldn't be
necessary. The coding problem is solved now. But apparently my
understanding/configuration of removeAbandoned is not correct.
Possibly, but you didn't state your expectations.
I'd like to have that figured out in case there's a next time (which
sadly there probably will be....). Basically, with the configuration
below, I'm not getting any idle connections detected and returned.
This is TC 8.5.73. And the leak was happening on a basic
request/response (no threads involved). I requested the connection,
encountered an error, and returned without closing the connection.
Ideas? Thx.
-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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org