How to get the number of "keep-alive" connections ?

[Svetlin Zarev]

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 ?

Best regards,
Svetlin

[André Warnier (tomcat)]

Hi.

Post by Svetlin Zarev
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-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

Post by André Warnier (tomcat)
Hi.

Post by Svetlin Zarev
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".

In this case, "keep-alive" almost certainly means "HTTP Keep-alive"
which means that the TCP connection is still up AND the server is
waiting for more requests on the open connection.

Post by André Warnier (tomcat)
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).

The default for HTTP 1.1 connections is that keep-alive should be
enabled. That is, in the absence of a "connection" header from either
the client or the server (in the response, of course), the connection
is assumed to be remaining open.

Post by André Warnier (tomcat)
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 it gets more complicated when servlet-async is involved, or
Websockets.

Post by André Warnier (tomcat)
And the corresponding proper naming of a variable which would
contain this number, is probably just as contentious.

Agreed: there is probably a way to get the count of "keep-live
connections", but what is the real objective, here?

Connections in the keep-alive state only consume a little bit of
resources to keep them open when using an NIO-based I/O model, so you
won't likely run out of threads, but you could run out of TCP ports.
If that's happening, you need more hardware :)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrndOkACgkQHPApP6U8
pFi71xAAtCmWtpdRm8GKUg9Z8mcT5dmBD2w19Uj/z/7mGjlx8hLpdX7TQggT2zw1
tOaD7hyZIdDwJHpnWw1jD5waznGX1oEXzvBFKEbHU40wtxuIkV4MA/hjOU+N/FhT
qDEVPgeQS3mMyIQJA2hpzpIxBEOCfmLtx8IYEWiyLexeHhbcJsGaf+fyRwNRQok5
u5IS5YActBY0SoRuiSQBQkTAtcntJQ4ADenciQCXXXeOA2F54SsEZO2+keBcqaZ5
HDAif1o3VLCcjxnzycXXbtgOWKoHBL5gqiteLOy/MaPe+xbDqK6xJ9wOzzLPFb+y
sTBTFVR2nwQ6zASIXD4nG7uSNOsaSnBo1yebEeSGSZ89+R2j8hycUhgVHzNnqRT6
Ax/Th6Kt0vjpt/MuL5NrNWKSv2UdWQw3m4JkNnQFv0sAQv1jbDdOi01Y6XGwr0Hv
YkFz2DZKbPJ20yvZ9T1CgeiPr2rLVjPDhyVsQQQWyeB+g59RWHDfWX7RNa0hAP8R
NGeCefMm5yVrLTAfLFWoj9Zprk9OBPPsVgCmMxwkSoVeoow/Ef1hDlGu0pE+hz0Z
gcq49+ucPLVUiL28J9t/LCk4cz9fCJu3J9cU1aRecRHMuOJVO7ueJcxJaNQ5OQd8
S8aJgRqSJxNevuhJRb2A/c0xBxBi7G1SnoCqxHn1hXpXs/vxUak=
=S8A/
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org