On 29/01/2019 17:54, Christopher Schultz wrote: > 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.
It means that the client IP / session ID mapping is removed from the cache after 60s. If the requests are at 5 minute intervals you want this to be at least 300 plus a bit for timing differences. I'd probably just use 500 (or 512). > 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. :) The info above should be what you need. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
