On 09/09/09 22:16, Ed Hillmann wrote:
> On Thu, Sep 10, 2009 at 12:25 PM, Jan Luehe <Jan.Luehe_at_sun.com
> <mailto:Jan.Luehe_at_sun.com>> wrote:
>
> On 09/09/09 18:30, Ed Hillmann wrote:
> This should work.
>
> What do you mean by "My sessions are not kept at all"?
> Are you still seeing your sessions getting expired after 30 minutes?
>
> Thanks,
>
> Jan
>
>
> I mean my sessions are not kept at all. The next time I do anything
> with the loaded page, I get an error saying my session has timed out
> and I'm redirected back to my Login page (as per my application's design).
>
> Even better, my application is using ICEfaces, which performs an AJAX
> heartbeat request back to the Web server. So, when I get to my login
> page, after a second I get a popup notifying me that my session's
> timed out and get redirected back to the login page (as per my
> application's design). I imagine that the AJAX call is attempting to
> call back to its session (as it should) which has been made invalid by
> the server.
>
> So, when set to 0 or -1, it behaves quite the opposite to what is
> described in the documentation.
>
> I'm even more confused, as I'm even trying to set it programmatically
> via HttpSession. According to it's javadoc,
> I should be able to call setMaxInactiveInterval
> <http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpSession.html#setMaxInactiveInterval%28int%29>
> to a negative value to define that sessions shouldn't time out.
> However, even when I do that (and stop using either of the
> descriptors), it still times out after 30 minutes.
>
> I didn't think I needed to do anything else, but I'm happy to try
> something else if it will do what it's supposed to do.
Can you declare an HttpSessionListener in your web.xml, whose
sessionDestroyed
method prints the session id of the session that is being destroyed,
along with
a stack dump (Thread.currentThread().dumpStack())?
You may want to add similar logic to the sessionCreated method, so that
the sessions
being created and destroyed can be correlated.
The stack dump should tell us who is destroying the session.
Thanks!
Jan
>
> Thanks,
> Ed