Hi Greg,
On 11/1/12 3:05 PM, Greg Wilkins wrote:
>
> 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.
Well, they are clearly related at the time of the opening handshake. So
I think we can depend on getting the user's identity context used to
initiate a web socket connection, for example. And I think we should
require that if the user invalidates the session (e.g. by logging out)
we should close any web socket connections that were initiated under
that session.
But, yes :( What it looks like we may not be able to do is to require
the http session be kept alive if only the web sockets in a web
application are active if there are no http requests. I think we should
probably let containers do this if they have some informal strategy to
do it, but not require it.
OK with everyone ?
- Danny
>
> cheers
>
>
>
> On 30 October 2012 09:53, Danny Coward <danny.coward_at_oracle.com
> <mailto: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 <mailto:gregw_at_intalio.com>>
> http://www.webtide.com
> Developer advice and support from the Jetty & CometD experts.
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation