Add support for multi-instance apps #1913
Conversation
jonatanklosko
force-pushed
the
jk-multi-instance
branch
from
b78d856
to
fd5b725
Compare
|
Uffizzi Preview |
jonatanklosko
force-pushed
the
jk-multi-instance
branch
from
0d27585
to
5992bab
Compare
| # Zero-downtime deployment is not applicable to multi-session | ||
| # apps, since they are inherently zero-downtime. We reset to | ||
| # the default, so we do not persist it unnecessarily | ||
| |> put_change(:zero_downtime, false) |
| end | ||
| defp app_report_client_count_change(state) when state.data.mode == :app do | ||
| client_count = map_size(state.data.clients_map) | ||
| send(state.app_pid, {:app_client_count_changed, state.session_id, client_count}) |
There was a problem hiding this comment.
Why are we reporting to the client instead of keeping it in the session and then querying the session? Or is the goal that we never have to query the session because all information is in the app?
There was a problem hiding this comment.
We report it to the app process, which updates the tracker, so when we list apps we can show the current number of clients for each session.
There was a problem hiding this comment.
Oh, otherwise in a cluster we would need to do a bunch of requests to each session in the cluster, right?! Sounds good to me.
There was a problem hiding this comment.
Yeah, for listing we want this information in the tracker. And for the apps listing all information we need is in app.sessions (and those maps include different information than sessions in the tracker, since we care about different information in case of apps).
This adds a new multi-session mode when deploying an app. In that mode, multiple sessions (instantiations) of the app can be started by going to
/app/:slug(depending on configuration, either by the clicking a button or automatically). Sessions can automatically be closed on inactivity (a period with no users).User Interface
Settings
Apps page
Multi-session app page
Technical details
So far an app was coupled to a single session, registered using
:globaland managed ad-hoc. Now an app may exist without any sessions, so I separated the concerns.Each app is identified by a slug and has a process responsible for starting/stopping sessions and tracking relevant information. App processes are registered using
Phoenix.Tracker, the same way we do for session processes. When deploying a notebook, we check if the slug has an app process (a) if no, we start it; (b) if yes, we tell it to deploy the notebook as a new version.The app process takes care of starting sessions when requested or eagerly (for single-instance apps) with optional zero-downtime deployment. It also takes care of closing the sessions depending on the configuration (a) never; (b) on inactivity; (c) when new version is deployed.