Resending from the right address.
On 13/07/2012 01:23, Danny Coward wrote:
> Hi folks,
>
> I think this will probably get to be a discussion, so let me start the
> ball rolling:-
>
> As the API stands, each Endpoint handles the lifecycle events of its
> multiple peers, there is a choice as to whether to say that the
> implementation is allowed to call Endpoint methods concurrently, or
> sequentially. The latter might be more convenient for developers; and
> may not 'cost' too much in scalability since one could argue that
> connect/disconnect events are not so common as, say, messages going back
> and forth.
>
> And if the developer uses a separate MessageListener instance per Peer
> (as the API suggests), then the onMessage methods on each instance are
> only ever called sequentially (assuming I'm correct that the websocket
> protocol is designed with only one message at a time per socket).
>
> Would that approach, essentially meaning that only one container thread
> at a time hit the connect/disconnect and onMessage callbacks at a time
> an acceptable balance of developer convenience and scalability ?
>
> Or should we think of specifying something more like the servlet model,
> where connect/disconnect and onMessage callbacks could be called
> concurrently by multiple threads. More of a burden on developers, and
> would probably need some rejigging of the API.
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.
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?
Mark