On 31 May 2017 at 10:11, Mark Thomas <ma...@apache.org> wrote: > > >> > >> > > 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 looses then state. Like i said below, our application is a statefull application but we use websocket what was previously ajax request to push back and forward changes to server and client (so a data change on the server is pushed right away to the client) We have our own session tracking over the websocket url: wss://domain/websocketendpoint/sessionuuidparam the first time that sessionuuidparam is null but then we push that value to the client and store it in the session storage (so that tab in the browser) and if we do a refresh or a reconnect then we send that session uuid to the server and the server will connect that new websocket endpoint to our "session" object So a new context would not find that session object because i guess that is a fully new classloader/application deploy... so we lost the session. In the ajax version this would not happen because that is all pure async http request to the server with a http session object.. > > > 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? > No we wouldn't close it on the websocket connection close, but on the timeout of the Session object that is behind that connection And if before the time out happens a new websocket connection is coming in (with the above url) then we quickly re attach the session object to that new endpoint and it will go on only after a while if there is no new websocket being setup, we invalidate the session object (and then we could also invalidate the http session that we stored) So in the end this is just kind of the same as http sessions in tomcat... but then real session support over multiply request for websockets And we don't use a cookie but purely have the id always in the url because this way multiply tabs in the browser are always independent of each other. So it would be nice if tomcat would have versioning support for websockets under the hood... Like a setting that we could turn on and then when an upgrade happens tomcat auto sends a cookie which it reuses to connect to the right context version johan
