> > > 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?
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.. 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
