Hi.
A question at the end.
On 26.03.2018 22:01, Shawn Heisey wrote:
On 3/26/2018 11:28 AM, Christopher Schultz wrote:
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.
That is a key piece of information. And it should have perhaps been
obvious from the description, but it wasn't. I have been thinking this
whole time that when abandoned connection removal is triggered, the
connection was closed as well as removed from the pool.
If the removal is literally just "take the object out of the pool" then
it sounds like that removal isn't going to affect the application USING
the connection either -- so the customer probably doesn't have any
reason to sharpen their pitchfork. If I'm right, the connection may get
removed from the pool, but as long as the query doesn't throw an
exception, JDBC is still going to plug along and return results just fine.
Is there any facility in the pool that can actually close an abandoned
connection? Yes, I am aware that ultimately the responsibility for that
is ours, and represents bad programming. Just hoping the pool can make
the problem invisible to users.
Just to ask, since we're clearing up misconceptions ... when the idle
eviction thread evicts a connection, is that connection closed? At the
moment I don't think we have idle eviction configured, but it's
something I want to add.
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).
I will see about getting this into the existing config. And brace for
the flood of log messages. ;) I have added it already to the new config
I'm working on.
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.
Yep, I've already got the gears turning to get that lowered.
Just a question, more to satisfy my curiosity : when you have these hundreds of "pending"
connections, in what state are they, TCP/IP-wise ?
You can find that out with the netstat command :
- under Linux, something like
netstat -pan --tcp | grep "(destination ip and/or port)"
- under Windows, the netstat command also exists, with slightly different
parameters.
(destination ip and/or port) : put here the IP and/or port of the back-end system(s) to
which these connections are made; this is just to reduce the number of lines..
The prior to last column should list the status.
The last column should show the program and PID of the process "owning" these
connections
(in your case, that may just be "java"; but the PID may tell you more.)
The reason I'm asking, is because some years ago I was bitten by a bad programming issue
also related to connections not being properly closed, and maybe this is similar.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
