Thanks!
On Tue, Nov 26, 2013 at 11:48 AM, Mark Thomas <ma...@apache.org> wrote: > On 25/11/2013 10:58, Nir A wrote: > > Hello, > > > > In our current generation web application we used session replication > with > > tomcat clustering. (and a load balancer) > > That way, we recieved an auto failover when a client sends an ajax > request > > to a tomcat node that failed. > > > > In our next generation web application, We would like to have a similar > > behaviour, only with websockets. > > > > So my questions are : > > > > 1) Is it possible ? > > Maybe. It depends exactly what you want to do. > > > 2) Does it involve websocket-session replication? if so, are there any > > guides on how to do that? > > Like HTTP, WebSocket is a stateless protocol. > > Unlike HTTP, WebSocket has no (that I am aware of) standard mechanism > for session management. This makes fail-over tricky. > > You can (with JSR356) link the HTTP session to the WebSocket session. > The main issue is that unless there are HTTP requests to the session, > the session will expire so you either need a long timeout or you need to > be sure other requests will maintain the session. > > If you store data in the HTTP session rather than the WebSocket session, > Tomcat's standard session clustering mechanisms will provide session > replication. > > Another issue is the load-balancer. I'm not sure of the state of > WebSocket support in the usual suspects for load-balancing. I took a > quick look at httpd's WebSocket proxy support but it appeared to be > based on the invalid assumption that all WebSocket endpoints would be > under a single URL e.g. http://host:port/context/websockets/... whereas > JSR356 allows the same URL to support both WebSocket and non-WebSocket > requests. > > This is definitely an area where there is work to do. It needs folks > with real requirements to see what works and what doesn't and then raise > bugs / enhancement requests to fix the problems and fill the gaps. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
