Hi, actually the issue got resolved. The system in question wasn't tomcat but jboss (hence the offtopic) and in particular undertow. Undertow seems to have completely different session expiration handling than tomcat, they actually prolong expiration timestamp every time an attribute is accessed...
Thanks for the insights! Leon On Mon, Aug 27, 2018 at 9:07 AM Jäkel, Guido <g.jae...@dnb.de> wrote: > Dear Leon, > > I suggest to use the Tomcat Manager Application to investigate the session > data: > > * Use the Session Display (/manager/html/sessions?path=/foo) to take a > look on the different Timers (Creation Time, Last Accessed Time, Used Time, > Inactive Timemm,TTL) or even the session data > > * Use the Connector Scoreborads on the Server Status Display > (/manager/status) to detect stuck requests. I'm not sure if a stuck request > may prevent a session cleanup (especially of "other" sessions) > > Another approach may be to snapshot a memory dump and investigate the > session objects, e.g. with the Eclipse Memory Analyze Tool (aka MAT). > > Greetings > > Guido > > >-----Original Message----- > >From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] > >Sent: Friday, August 24, 2018 11:25 AM > >To: Tomcat Users List <users@tomcat.apache.org> > >Subject: [OT] What can prevent sessions from timeouting apart from real > requests > > > >Hi, > > > >one of the systems we are consulting has encountered a strange problem. > The > >sessions will build up indefinitely but never expire. Then, at one point > >(at 02am in the night, 19K sessions would drop at once). > >Of course the simplest explanation would be that someone is actively > >requests something every 15 minutes (session timeout) keeping track of the > >JSESSIONID. We are trying to track this through the access_log and such. > >However, my question, is it possible to prevent session from timeouting by > >doing something stupid code-wise? Like storing a session in a hashmap > >somewhere, and accessing some attributes from time to time? My > >understanding was that the session timeout is solely dependent on incoming > >requests and handled by the container, but I was not 100% sure ;-) > > > >Thanks in advance > >Leon >
