-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for multi-instance apps #1913
Conversation
b78d856
to
fd5b725
Compare
Uffizzi Preview |
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
:global
and 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.