Peter Warren wrote:
A comet read event doesn't update the last accessed time of an
HttpSession -- which means comet read events will never prevent an
http session (not the comet session) from timing out and the
connection getting closed.
Is that by design? If so, can anyone offer me suggestions on how to
handle long-lived comet connections that may outlive the http session
timeout?
session.setMaxInactiveInterval on the BEGIN method.(set to very large or
unlimited)
session.invalidate on ERROR or END (only if comet is the only thing
doing stuff with the session, otherwise see below)
I had been hoping to periodically send a comet read event to update
the access time of the http session. But, given that comet reads
don't affect access time of the http session, it seems my best option
is to periodically close the comet connection and open a new one. Or
is there a way for me to programmatically update the http session
access time (I couldn't find one in the HttpSession docs)? Any other
thoughts?
a regular HTTP request to anything but the Comet URL will update your
last access time,
so if you have other servlets/jsp etc under the same session, those will
update your last access time.
when it comes to "comet session" data, you're probably better off
managing that yourself
Filip
Thanks,
Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
