Session & Environment timeout

[pichoemr]

@lenra-io/devs

Environment & Session timeout

We need to think about timeout so for now i remove timeout in this PR. With this change, we stop the session supervisor and all supervised genserver when the socket close, on closing we notify the Environment's Dynamicsupervisor which checks if there are still sessions using the environment, otherwise it stops itself.

For now what i think about timeout:

• Session Genserver timeout in 5 minutes
• Environment Genserver timeout in 5 minutes
• restart type: transient (restart only if stop status are not :,normal or :shutdown)
• implement handle_info that receive :timeout, return {:stop, } where status can be :normal or :shutdown,
  • :normal, stop the genserver
  • :shutdown stop the genserver and all linked genserver

In my opinion, the overall logic we need to use to properly manage timeouts is as follows: when a genserver is in timeout, we notify the corresponding supervisor who closes the session and/or the environment, depending on the context.

Here are some ideas, feel free to comment.

Session

For the session, we can add a timeout on RouteServer and stop SessionSupervisor on the timeout, we can also keep the supervisor shutdown on the socket shutdown.
We keep the notification to the environment with Environment.DynamicSupervisor.session_stopped.

Environment

For the environment, I think we need to add a timeout on the view server. When a view server stops, the environment is informed and if no other view server is running, we can stop the environment (and the session, but actually all sessions normally have timeout before).

Restart ?

With this idea we can have a case where the socket is still running, but after 5 minutes the session expires and after 10 minutes it's the environment (in case we are the only person using the environment), so the user can still run the headphones, should we implement a restart for the session and / or the environment or we send an error message to inform the user about the timeout ?

[taorepoara]

IMO the first timeout that we have to add are the one for components that are never closed properly. If the last user of an app closes his browser, all the environment elements should stop.

We then can use timeouts to optimize some resources. For example:

• timeout on environment to close it only 5 min after the last user disconnection to keep cache for a re-connection or another user
• timeout on view cache to clear cache of a view when it's not on any user client since the last 5 min

[pichoemr]

This is actually the case with this RP lenra-io/application-runner@d12b4b2

This discussion is for, how to re-implement the timeout correctly if we decide to re-implement it.

[Nesqwik]

The Session should be bound to the user socket if i'm not mistaken.
This means when the socket stop, we can stop the associated Session aswell.

Then, when a session stop :

• check how many remaining sessions there is under the env
• then stop the env if there is none.

And if an env stop we could scale to 0 the openfaas deployment.

This also means :

• When an env is started, Scale the openfaas deployment to 1 and WAIT until it's deployed before continuing.
• Check the startup time of the openfaas deployment. If it's too long, we might want to avoid this...

[taorepoara]

The scale to 1 is automatic with OpenFaaS. The first call to the app will scale to 1 and wait the readyness probe before sending the request. This is transparent for us, but the first request might be long.

[Nesqwik]

Ok then basically we simply decide if we want an "inactivity timeout" to wait a few seconds/minutes just in case he come back or stop the session/env directly.

We might want to add a timeout for the session but none for the environment.
With this timeout, the user is able to refresh his page without restarting the session but he disconnect for a few seconds/minutes, we stop the session and the Environment if he was alone. Then, scale to 0 Openfaas.