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