[jetty-dev] Jetty session expiration

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] Jetty session expiration

Marc Klinger
Hi,

I experience problems with Jetty sessions expiring too early. I do
cross-context-dispatching. Every context gets an own session object from
Jetty but is sharing the same session id (JSESSIONID cookie). Then, when
the first session object times out, all session objects using the same
session id are invalidated.

I assume this also to happen in a "normal" webapp environment (without
cross-context-dispatching) with a root application (context path "/")
and another application (e.g. context path "/foobar"). Both applications
use the same session id but different session objects. The session that
times out first will destroy all other sessions with the same id.

I am using Jetty 8, but the same problem is already described for Jetty
6 here:
http://jetty.4.n6.nabble.com/incorrect-session-invalidation-td35263.html

The root cause of the problem is the AbstractSession.invalidate() method
which calls AbstractSessionManager.removeSession(this,true). This may be
the desired behavior when calling HttpSession.invalidate() from within a
web application.

However, session timeouts should be handled differently. I would expect
the session access time to be "synchronized" between sessions with the
same id in some way (which would result in the shortest session timeout
to win) or only to invalidate sessions when all sessions with the same
id are ready to be invalidated (which would result in the longest
session timeout to win).

The same problem appears when a context gets stopped. All sessions of
this context get invalidated which also invalidates all sessions with
the same ids from other contexts. This may prevent persisting sessions
correctly (it depends on the order in which the contexts are stopped).
Hot-deployment of contexts destroys the session of all other contexts
with the same session ids.

What do you think about this problem? Should I open a bug for this? I am
willing to contribute code if one of the solutions described above would
be acceptable or someone can point me to a better solution.

Regards,
Marc
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Jetty session expiration

Jan Bartel-3
If you'd like to contribute code to do some kind of
expiration-synchronization between contexts, then we'd certainly be
open to it.

Please open a bug for this over at Eclipse:
https://bugs.eclipse.org/bugs/enter_bug.cgi

Please also familiarize yourself with Eclipse's policy on IP and code
contributions: http://wiki.eclipse.org/Development_Resources

cheers
Jan

On 3 April 2012 23:13, Marc Klinger <[hidden email]> wrote:

> Hi,
>
> I experience problems with Jetty sessions expiring too early. I do
> cross-context-dispatching. Every context gets an own session object from
> Jetty but is sharing the same session id (JSESSIONID cookie). Then, when the
> first session object times out, all session objects using the same session
> id are invalidated.
>
> I assume this also to happen in a "normal" webapp environment (without
> cross-context-dispatching) with a root application (context path "/") and
> another application (e.g. context path "/foobar"). Both applications use the
> same session id but different session objects. The session that times out
> first will destroy all other sessions with the same id.
>
> I am using Jetty 8, but the same problem is already described for Jetty 6
> here:
> http://jetty.4.n6.nabble.com/incorrect-session-invalidation-td35263.html
>
> The root cause of the problem is the AbstractSession.invalidate() method
> which calls AbstractSessionManager.removeSession(this,true). This may be the
> desired behavior when calling HttpSession.invalidate() from within a web
> application.
>
> However, session timeouts should be handled differently. I would expect the
> session access time to be "synchronized" between sessions with the same id
> in some way (which would result in the shortest session timeout to win) or
> only to invalidate sessions when all sessions with the same id are ready to
> be invalidated (which would result in the longest session timeout to win).
>
> The same problem appears when a context gets stopped. All sessions of this
> context get invalidated which also invalidates all sessions with the same
> ids from other contexts. This may prevent persisting sessions correctly (it
> depends on the order in which the contexts are stopped). Hot-deployment of
> contexts destroys the session of all other contexts with the same session
> ids.
>
> What do you think about this problem? Should I open a bug for this? I am
> willing to contribute code if one of the solutions described above would be
> acceptable or someone can point me to a better solution.
>
> Regards,
> Marc
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev