-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chedana,
On 6/23/15 10:40 AM, chedana jayasinghe wrote: > I just put a debug point an checked. In tomcat 6,the request comes > to the servlet with a null session,but in tomcat 7 and later > versions the valid session is there in the request When you say "the session is there in the request", do you mean that calling request.getSession(false) returns something non-null? Something must be tripping the loading of the session, which is why I was asking last week about using "Strict servlet compliance", because that will always update the last-touched-time of the session even if they web application doesn't try to access the session. Have *anything else* changed? Can you create a Filter that wraps the request and reports all calls to getSession(boolean) to a log file? If you can't catch it there, you might have to write a Valve to catch it at a lower level (so you can see if Tomcat itself is accessing the session). - -chris > On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <a...@ice-sa.com> > wrote: > >> chedana jayasinghe wrote: >> >>> In my web application, in a jsp there is a javascript which >>> sends request to a servlet every twenty seconds, so it kills my >>> applications user idle time tracking by resetting the >>> lastAccessed time in session. the funny thing is lastAccessed >>> time doesn't get updated in tomcat 6 and my applications idle >>> time tracking works fine in it, but in 7 it gets updated and >>> kills that functionality of the application . so I'm little >>> bit confused about the changes in the session tracking of >>> tomcat 6 and tomcat 7. >>> >>> >> I don't know what happened in Tomcat 6 as compared to what >> happens in other versions. But from a purely logical point of >> view, I would tend to think that, from the server point of view, >> whether a request comes from the user pressing a button or from a >> javascript module in a page sending a request, does not make a >> difference : the application has been accessed, so the "last >> accessed time" should be updated. That is probably the point >> even, of many such javascript snippets out there in the wild. >> >> So again from a purely logical point of view, if Tomcat 6 then >> did not update the last access time, that would sound more like a >> bug, that was corrected later. >> >> Maybe the fact that it updates this or not, depends on whether >> the application that is called retrieves the session or not, and >> if so you may have control over it, by making sure that whatever >> your javascript calls, it does /not/ retrieve the session. >> >> Caveat : I do not really /know/ how it works, so there is a lot >> of speculation here. >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJViYGXAAoJEBzwKT+lPKRYZ08P/3tWuZ0oQuntLFCWWNyS1DPf vr+cpisBd0CIMRPgJYvLu28ocrsb1piCdoXK1GaLmwduyjQPlXcoxRRelfUTkjmj adxN/NTQVi6k3NOVd80dpPfYu0gFeZ0GhYXp5tJnuchBrRLcwITVbrV9OZ0BXCgK Pu9jWiH53GZGWyFRv3eeX3QdYi9a3IH438sX1lBfhDyQcqlAPvtaq9Uc961/ypcj 9yu5exlOQU6hzlHNGNnjhcS1JSq1+sJ4sF8WCyIsV28orXtmHLLv3SgOgM4XniR9 hHDVffXuap8l9U2pf0EGOoAfNhd5Eim8uqhrUPLuKA55u9c1IlRQ7abYUML4AOWt SikPikd/9lvv4HPujE2jV/xl6fRlEMetGtckQRHrlgorMNDvO/OUSZNVfEW/9PgR 8/qagq+Wew4bQPWfsWDkE3ZfN1YD2HWx4f35ErEZFY5NgxXjMGDNoRmD9aXSLf5m mpFqp5NL7Vy+3tNjTAaEVdK3n60Xhko2WQlaH65A+8dSbJD4giVY01HSYGvzF7H6 Uth0N2ij6wJ3VL8bZdezsHZhgrQ0OMWGl6AtqDcjsPgtDFOY43uG5AlG5dITjLyX MO41HhjL0WO+gC4aI2k+ksoNNspYYzzoOT2ccQAKhpPUieRTj41efmJqWLP2tkQM bYGEYdD4zvwfdLDqaPu8 =PUtU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
