-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/28/19 04:21, Mark Thomas wrote: > On 25/01/2019 23:11, James H. H. Lampert wrote: >> This is also about our clustered Tomcat 8 application running on >> Google Cloud. >> >> The Report sub-cluster runs BIRT. And the default landing page is >> the Eclipse BIRT viewer default landing page, the one that shows >> an Eclipse logo, and says "BIRT viewer has been installed." >> >> I've got a health-check on that sub-cluster, that polls the >> default landing page of ROOT periodically. Up until a few days >> ago, it was polling it every 5 seconds; earlier this week, I cut >> it down to every 5 minutes (the maximum); now I've got it at >> every 30 seconds. >> >> If I open the Manager context, I find that it shows (currently) >> around 180 sessions for the ROOT context. When it was going every >> 5 minutes, it was showing 18 sessions; when it was going every 5 >> seconds, it was up to over a thousand. >> >> The other two sub-clusters don't have any dangling sessions from >> their health-checks; why would this one? >> >> I'd like the sessions from all this health-check polling to >> expire a bit more quickly; can anybody here suggest a way to >> accomplish that? > > http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Crawler_Sess ion_Manager_Valve > > Set the crawler user agent and/or crawler IP appropriately so > your load-balancer is treated as a web-crawler and all those > health-checks will be associated with a single session. We recently implemented this at $work and I'm not sure it's behaving as I expect. For example, we aren't seeing a reduction in session count. We have 5-minute interval health-checks and the default for sessionInactiveInterval is 60 seconds. Is the problem that the sessionInactiveInterval is expiring between the healt-checks? Does the HttpSession created for the "Crawler" expire after 60 seconds (well, sessionInactiveInterval)? Or does it inherit the server-wide session-expiration? The latter does not make any sense because that session would never be accessible again, anyway. My expectation was that one and only one HttpSession would be created and all clients matching crawlerUserAgents would re-use that same session. If the session timed-out naturally, it would be re-created on-demand, so the number of sessions on the node would be roughly equal to the number of "real" users + 1. I'm starting to think that it's more complicated than that. I'm of course going to go read the code, but it would be better if the documentation was more descriptive so that a code-dive wasn't necessary. I can, of course, patch the documentation as well. :) - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxQk28ACgkQHPApP6U8 pFgoMRAAoCyyY7OiwdB2HfXs3+sLklWQZ4kOeVwPYM/GRbWEuc3AG+q4tj/lrgLU L9f5LpoWPAxj30xeEukgyKLqt9B60iJXtAucvCIKIfCfViom6mT9kSinijv4qGmR puwozzYwoOhDqCyGy1hOugzXzyW78XVNZjGW0mlTA4OyhTddmKiNs1xmHdF/AUIh FSK1O26xCq/19od0TJYznMhy9vgOSYbCgpNpZSy7N1wV8Mlx+cicrVLTdU2nNdnC 9/z3tzLb2xL6OusUL8XhBX0FrCiZ26suPtLC73E3CwDWeUCWB7vZncRhOJKFWwvO xwJbdsha0FdNhPime6RzVKbdOE4WY+fyuFL2Z9SYMzA1zFpUb9rvky8E/cHf7fC9 QWjTCp9nVgsSLc+aBjwh842sR6EBBkSt9oQX5RX7AAeC6yy7TazX3rDRV0I7sjmB vkrebTV+W0RjbPF3liHtqoBv+hcOj4vmaSxTd2IifvMRRTOUYl17FLLBI/IKFIG3 A9mxrNgYLtsoehhtlonaq+QeiDDF0TZjwaZPFU0RtXg7nhQ0p8KTrsBqzwz6lCbK fmL8cJ9V3XVtWEnnodDgN2v+lROdhk0OUzvqdPCsBlU2ZPE7o40MOxPqmsdM9+cG 33GeqDsvy6mXSG6nQW+T+D4LMsPAdkh6PHNJMNKZcfeZM2OOPFo= =Tp1k -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
