We've bumped against this problem, but not really found a solution nor
found it a total show stopper.
Without browser support, there is no way to refresh the cookie on the
client side. So to keep a HTTP session active, either the application has
to arrange for an occasional HTTP request, or even to occasionally drop the
websocket connection and force a rehandshake.
Unless we advocate for a setCookie frame we can send over websocket, I
think the only solution is to simply say that the HTTPSession is unrelated
to the Websocket connection.
cheers
On 30 October 2012 09:53, Danny Coward <danny.coward_at_oracle.com> wrote:
> Hi folks,
>
> One of the outstanding issues we had was to figure out how to 'touch' the
> http session to prevent it timing out. This you might remember was for the
> case where a user has logged into web application containing web sockets
> (e.g. stock trading with live updates). The user doesn't issue any more
> http requests, but the websocket sessions are still open (ticker updates).
>
> We talked this through with Rajiv - we can use
> httpsession.setMaxInactiveInterval to postpone (indefinitely) the expiry of
> the http session on the server at any time. But the client cookie will
> retain the expiry time of its last http interaction. In which case, it
> seems that a browser client will clean out the cookie and the session will
> effectively be lost. Obviously we can't set the expiry of the cookie to an
> irresponsibly long time.
>
> Has anyone come up against this problem ?
>
> - Danny
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.