[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Session timeout
|
On 06/09/2017 03:55, Jan Bartel wrote:
John,
As you can see on your log trace, each session contains a timer that
expires when the session maxInactiveInterval is reached. When the timer
expires, that session is queued for attention by the scavenger. By
default the scavenger thread only runs once every 10mins, so it is
timing dependent exactly when the session will be scavenged wrt when the
session expires. Note that an expired session that has not yet been
scavenged is not able to be used, as you have discovered. The servlet
spec does not stipulate any relationship between when a session expires
and when the sessionDestroyed listeners will be called, only that an
expired session cannot be used, and that the listener must be called
when the session is actually invalidated (expiry and invalidation being
2 different things).
OK. However, what I see in the spec for HttpSessionListener is this:
void sessionDestroyed(HttpSessionEvent se)
Receives notification that a session is about to be invalidated.
That "about to be" suggests that the session should not be invalidated
until after sessionDestroyed() has returned, and should therefore still
be accessible inside sessionDestroyed(). Certainly when debugging I can
see that the session object still exists, and still contains my "state"
attribute -- and of course I used to be able to access it in all
previous versions of Jetty back to the early 2000's when I first
deployed this app in a production setting.
If your interpretation of the servlet spec is correct, then it would
appear that now my app will need to maintain its own HashMap of session
IDs to state info if I want to be able to write log messages to record
sessions being invalidated with information about which user it was etc.
In this I might as well not store anything in the session itself and
just use the session ID to access my HashMap (assuming I can still
access the session ID inside sessionDestroyed(), which I haven't tried
yet). This seems rather silly, since the primary purpose of the session
object is to maintain this sort of information for me.
--
John English
