Bugzilla – Full Text Bug Listing
| Summary: | HttpSession.setMaxInactiveInterval needs really good accuracy | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | David Jencks <david.a.jencks> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jetty-inbox |
| Version: | 8.0.0 | ||
| Target Milestone: | 7.1.x | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
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? 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. |
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.