On 31/05/17 08:38, Johan Compagner wrote: >> >> >> 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. >> >> Mark >> >> > would a feature request be accepted for this that there can be a cookie set > where that "load balancer" would also look at? > and that cookie always make sure that it goes to the context it started > from as long as that context is there?
Maybe. What is the use case? Why can't a new WebSocket connection be created to the new version of the web application? > Because it is quite annoying that it is tied to a jsessionid of a > HttpSession that should then be created and kept alive for the whole > websocket session.. > > i can do something like this: > > https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint > > but isn't that kind of doing something that shouldn't be done? Like keeping > a reference to a http session? > > Even if i do the above then still i need to "touch" the session on every > websocket request to keep it alive > Or set the max idle time out to -1 so it never by itself invalidates() > And then when i know the websocket session is really gone i will call > invalidate() on it myself.. If you are invalidating the HTTP session once the WebSocket connection closes, why keep the session alive in the first place? Mark > > But this is all quite cumbersome > > We just have state there is no way around it, but the communication between > server and client is after the first startup completely over websocket > (just like ajax before)> > For example it would be nice if tomcat did this just under the hood. if > tomcat upgrades a http request to a websocket then it will also just push a > small cookie on it to know which context version it was on... > > johan > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
