In a similar situation, I do the following : * go full stateless, use no session ; * configure WS client to frequently reconnect * use atmosphere with an internal JMS backend, such as ActiveMQ, to share data transparently between parallely deployed versions.
With Atmosphere, you avoid losing messages on reconnections. Hope this helps. Ludovic Le 30 mai 2017 12:40:45 GMT+02:00, Johan Compagner <jcompag...@servoy.com> a écrit : >> >> > But now i have websockets, if i connect to ##1 first and i have the >end >> > point there >> > Then i add a ##2 version of the context >> > then i guess a new user that opens a websocket will go to ##2 >> > but if the existing user does a refresh in the browser then it will >also >> > suddenly go to ##2 i guess? >> >> It depends. If the URL in the HTTP UPGRADE request includes the >session >> ID, and that session ID is still valid in ##1, then the WebSocket >> request will be handled by ##1. >> > > >ah so for this to work we need to force a http session to be created? >so the cookie is set and the http session is there? >problem is a bit that all communication is then going through the >websocket >so the session could even just timeout, because we don't hit it anymore > >i do see when creating a websocket, request.getSession(false) is called >(multiply times by the way, a lot goes wrong when you have a breakpoint >on >that method, but thats another story) >but it isn't when it is just alive. So do i need to call something >every >time on the incomming() call in the endpoint to keep the http session >alive.. > >johan -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
