Some ramblings on this subject:
Session <> WebSocket
When you at first connect to a B4J WebSocket handler, two things are created:
- Jetty creates a new "session" for your browser. This "session" is managed by Jetty. If you look at your browser's cookies, you should now see a cookie named JSESSIONID. This cookie's value probably starts with "node". The expiration of that cookie is set to session, meaning that when you close the browser, the cookie "disappears". If you reopen the browser and reconnect to the site, a new Jetty session will be created. What happens to the old session? Looks like it will be kept around by Jetty since the default inactive timeout time for sessions is -1 (keep indefinitely). Please note, by default Jetty stores session information in memory and a shutdown of the Jetty server (be it a clean shutdown, a crash or a restart) will erase all session information (active and inactive).
- Jetty creates a new handler, which in our case will be a WebSocket handler. This handler can set/delete/access any information that it wants to in the above mentioned Jetty session. Alll information created will be managed by the Jetty server and the browser never sees it (except for the JSESSIONID cookie) without you explicitly sending the information to the browser.
Now, as long as there is no break in communications, the same WebSocket object will take care of all WebSocket communication. If, for some reason, communication failure happens, then next access by the client application will create a new WebSocket object (but not necessarily a new Jetty session). By using Jetty's session management, one can figure out if a newly established WebSocket object is either a brand new connection or a re-establishment of a previously existing connection (see
https://www.b4x.com/android/forum/threads/server-automatic-reconnecting-websocket.62054/). What happens to the old WebSocket? The JVM should clean it up, since it is not used anymore (unless you happen to keep it in some sort if list).
In regards to session management: in a lot of other web programming environments, part of a user log out procedure includes the invalidating of the active session behind the web connection.
So:
In my project (b4j - jServer), when a client connects and the user is authenticated, I add "its related websocket handler class instance" to a global project map (in which the keys are the users' IDs).
Ok
If the client's websocket was closed and then the client tried to reconnect, I thought that a new instance (websocket handler class) was created on server, thus containing its new websocket object and I would proceed by "replacing" the instance stored in the global map with the new one (actually copying some properties from the new instance to the old one).
It depends how it was closed. If the user closed the browser/browser crashed, the user will get a new WebSocket and a new session. If the WebSocket is closed, but not the browser, then a reconnection should create a new WebSocket, but you should still have the same session (unless it was invalidated).
Since in that thread Erel states that a session of a closed websocket will be kept active and it (the session) would be reused in case of client reconnection, now I suppose that a new instance of the websocket handler class will not be created.
The session will remain active as long as the browser is not closed. After a browser closes, that session is technically orphaned (on the Jetty side) and will not be used again. A server shut down/restart will clear all active and orphaned sessions. Any sessions after starting the server back up will be new sessions.
A new instances of a WebSocket will always be created if a WebSocket is closed or otherwise disconnected. A new WebSocket is not just triggered programmatically or closing the browser tab or the browser itself. A new WebSocket can also be triggered by timeout periods/inactivity and communication failure(s).
because I can simply use Session.Invalidate or set Session.MaxInactiveInterval as Erel suggested.
Yes. You can use Session.Invalidate before a controlled closing of a WebSocket (such as a log out) and the next connection will result in a new WebSocket and a new session. Session.MaxInactiveInterval can be used to clean up after cases where a user did not log out either by 1) period of inactivity 2) just closing out the browser or 3) a browser crash.
And if so, what exactly happens?
Hopefully I provided some insights (it's definitely not exact)
What events would be raised?
I don't think there are any (besides the events offered in the handler object)
How should the server handle this thing?
That may need to be specific to the implementation/purpose of the site in question