jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Multithreading Options

From: Greg Wilkins <gregw_at_intalio.com>
Date: Thu, 9 Aug 2012 09:47:21 +1000

On 5 August 2012 19:05, Mark Thomas <mark_at_homeinbox.net> wrote:
> The question this raises for me is what is the mechanism going to be for
> retaining state? i.e. what is the WebSocket equivalent of HttpSession
> going to be? The follow-on question is how is state information
> transferred between the WebSocketSession (for want of a better name
> right now) and the HttpSession.

In my websocket work to date, having websocket session has not been an
issue as we create an EndPoint per connection as a new object that can
hold state.

It is only if we go to a servlet-like model where we have the one
precreated instance of an endpoint handler that is handling multiple
connections that we have the problem of state. I think it is best
to avoid doing this and thus avoid the need for having a session
object (with all the poor concurrency semantics that the servlet
session has).


> Currently, my thinking is use the MessageListener to hold any necessary
> state and expose the HttpSession to it. That then raises the question of
> how to keep the HttpSession alive if there is a period of time greater
> than the session expiry time where there is only WebSocket traffic? Does
> the HttpSession expire or do we need to place a requirement on the
> Servlet EG to provide a mechanism to enable us to 'touch' the
> HttpSession to keep it alive?

As a lot of authentication mechanisms are tied to the session, I think
we probably need a way to touch the session and keep it alive.

cheers





-- 
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.