Hi.
On 30.04.2018 12:46, Svetlin Zarev wrote:
Hi,
The MBean "Catalina:type=ThreadPool,name="http-nio-8080"" has an attribute
called "keepAliveCount" but instead of the keep-alive connections it
returns the sum of the number of the pollers' selection keys (as a result
it usually reports a low number in the range 0-4 in my test setup). The
closest thing to that count is "connectionCount" from the protocol handler,
but it counts both keep-alive and non keep-alive connections.
So, is "keepAliveCount" just a bad naming/bug, or am I missing something ?
What's the proper way to track the number of "keep-alive" connections ?
That's an interesting question.
The first part of the answer is probably that for the TCP level of the connection, there
is no such thing as a "keep-alive connection". There are only (to simplify a bit)
"established connections".
The notion of "keep alive" is only a HTTP-level thing, and it just means that, rather than
immediately closing this client-server connection after sending a response to the client,
the server is going to keep this connection open (established) for a while, just in case
the client decides to send a new request on the same connection.
And in case the client does not send another request on the same connection before the
"keep-alive timeout" runs out, the server will /then/ close that connection.
And the server does that (I mean wait before closing), only if the client specifically
asked for such a keep-alive connection, when it sent its first request on the connection.
(Otherwise, by default, the server /would/ close the connection after sending the first
response).
All this to say that, from the server perspective, the "number of current keep-alive
connections" is probably not as straighforward as it may seem.
Such as : should it be the total number of client connections currently established, no
matter what they are doing (*) ? or should one subtract from that, the number of these
connections which are currently linked to a process which is processing a request ?
And the corresponding proper naming of a variable which would contain this number, is
probably just as contentious.
(*) because in a way, a connection is always keep-alive until the response to the last
request has been sent, and it only then gets decided whether to close it, or to keep it in
"life support" for some time longer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
