tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: How to get the number of "keep-alive" connections ?
Date Mon, 30 Apr 2018 19:56:26 GMT
Hash: SHA256


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

> 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
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message