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

[Svetlin Zarev <sv...@gmail.com>]

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

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

[Christopher Schultz <ch...@christopherschultz.net>]

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

André,

On 4/30/18 12:12 PM, André Warnier (tomcat) wrote:
> 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".

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.

> 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.

> 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.

> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

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

["André Warnier (tomcat)" <aw...@ice-sa.com>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org