Bug 49245

Summary: Servlet called with cross-context request can access a stale session
Product: Tomcat 6 Reporter: Konstantin Kolinko <knst.kolinko>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Severity: minor    
Priority: P2    
Version: 6.0.26   
Target Milestone: default   
Hardware: PC   
OS: Windows XP   
Attachments: webapps.zip

Description Konstantin Kolinko 2010-05-04 06:57:31 UTC
Created attachment 25396 [details]

When a servlet is called using cross-context forward/include call from another web application, its call to request.getSession(boolean) may return a session which was inactive for longer than configured session-timeout.

This issue was fixed in trunk in r926716

To reproduce:
1. Unzip the attached archive and deploy the two web applications contained there, "expire" and "expireB". "expireB" is configured to have session-timeout of one minute.
2. Access http://localhost:8080/expire/
The index.jsp page there will print current time and will display two sessions from both web applications.
3. Wait for 65-70 seconds and once more access http://localhost:8080/expire/
You may see the following output:
Current time: Tue May 04 14:44:16 MSD 2010

expire/index.jsp: Session:
id: 6124AB5790D0ABF2CD6472D63EE5332D
isNew: false
getCreationTime: Tue May 04 14:43:04 MSD 2010
getLastAccessedTime: Tue May 04 14:43:04 MSD 2010

expireB/index.jsp: Session:
id: 6124AB5790D0ABF2CD6472D63EE5332D
isNew: false
getCreationTime: Tue May 04 14:43:05 MSD 2010
getLastAccessedTime: Tue May 04 14:43:05 MSD 2010

Current time is 14:44:16 which is more that 1 minute more than lastAccessedTime of expireB session, 14:43:05. Observed: "expireB" reuses an old session. Expected: to use a new session (isNew: true) in "expireB".

I think this issue is a minor one, because it looks as the effective value for session-timeout configuration option is slightly greater that its literal value:

1) I observed no problems with the session. Even if the session was a stale one, session.access() call prolongs its lifetime. There was no IllegalStateException when calling its methods.

2) There is a background thread that cleans stale sessions once in several minutes (calls ManagerBase#processExpires()). This limits the difference between effective and literal values of session-timeout.
Comment 1 Konstantin Kolinko 2010-05-04 07:12:50 UTC
Fixed in 6.0 in r940804 and will be in 6.0.27 onwards.