Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 324601 - HttpSession.setMaxInactiveInterval needs really good accuracy
Summary: HttpSession.setMaxInactiveInterval needs really good accuracy
Status: RESOLVED FIXED
Alias: None
Product: Jetty
Classification: RT
Component: server (show other bugs)
Version: 8.0.0   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 7.1.x   Edit
Assignee: Greg Wilkins CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-06 17:48 EDT by David Jencks CLA
Modified: 2010-09-06 21:25 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Jencks CLA 2010-09-06 17:48:22 EDT
Some people seem to want setMaxInactiveInterval to have results within about 10ms of what is set.  One way to do this is to change AbstractSessionManager.Session.isValid() like this:

        protected boolean isValid()
        {
            if (!_invalid && !_newSession) {
                if (_lastAccessed + _maxIdleMs < System.currentTimeMillis()) {
                    invalidate();
                }
            }
            return !_invalid;
        }


However this adds another access of System.currentTimeMillis.  I suspect that the same kind of logic could be in the call chain of SessionHandler.doScope where it calls 

                        HttpCookie cookie = _sessionManager.access(session,request.isSecure());

(line 167 in jetty-8) as that also accesses the current time.
Comment 1 Greg Wilkins CLA 2010-09-06 20:59:43 EDT
Really??? How stupid!

If a request is 10ms late (easy with normal network jitter), then the session is invalid????   You get GC's longer than 10ms! Sounds like some silly test harness rather than any actual need.

Does this also mean that we should be scavenging at this accuracy?  or just on incoming requests?
Comment 2 Greg Wilkins CLA 2010-09-06 21:25:05 EDT
r2252

I put the fix in the access method, as the current time is passed in (avoiding another currentTimeMillis lookup) and the session is already locked.