ddelpiano
commented
4 years ago @Dario thanks for the explanation, but It's still quite difficult to follow the logic to me, in general there is more complexity than I expected. Probably a sequence diagram would help understand
That is exactly what's happening, we save the geppettoManager and we reload the saved one if the connectionID sent by the client match, differently we create a new one. I will create a flow diagram tomorrow and will link it here.
and would be useful to make something on the same line on the Python backend.
Would this be to be applied in https://github.com/openworm/pygeppetto ? Thx!
tarelli
filippomc
Backend websocket reconnection
Backend wise, the logic is based on the assumption that we need to save the previous geppetto manager instantiated in the first websocket session since this contains all the information added to the model before the connection will be dropped, differently if we handle only the websocket logic and we reconnect and instantiate a new ConnectionHandler and consequentially a new GeppettoManager this will let us use geppetto to add stuff Ui wise but if we request something that was already supposed to be in the model the whole UI will get crazy (massively out of synch and plenty of geppetto dialogs triggered by cascade errors).
For this reason as soon the onClose method is triggered we check the event status code, if legit we simply remove the project and close this connection, otherwise we save the current GeppettoManager through a set of getter and setter introduced in these changes and we park this a ConcurrentHashMap, stored in the singleton ConnectionsManager. This is stored with the connectionID as key, so when the frontend will realise that the connection has been dropped will send a reconnect to retrieve the geppettoManager from the previous connection that has been dropped. Here the backend will check if we stored this GeppettoManager, and if present will plug this in the current ConnectionHandler and remove it from the map struct.
Also, when we store the GeppettoManager in the concurrentHashMap, we store also the timestamp in seconds from UTC, everytime a new connection is instantiated we check the connections that have been dropped and now we also check the GeppettoManager parked in memory more than 5 mins, in that case we remove these to avoid to fill up the memory with no remorse.
This address the issue #901 (the branch has been called fix/177 by mistake since I opened this on the geppetto-client first, if necessary I can rename this).