Better handling of slow kernel startup

[blink1073]

References

#7403 #6007

See discussion in jupyter-server/jupyter_server#197 about the issues around slow starting kernels/terminals and a longer term solution.

While a slow kernel is starting, show it as being in "initializing" status with a filled circle and the name of the pending kernel. The user is now allowed to change the kernel while the previous session is starting. When a session is started, it shuts down an existing session so there is only one running session on the server.

We have to destroy an in-flight session connection rather than wait for it to finish. We properly shut down sessions that have been superseded. The classic notebook handles session restarts by destoying/creating, but does so synchronously. The user has to wait for the slow session to start before it switches. Classic notebook does not handle a change kernel request while the initial kernel is being created.

We use a unique id for the path when creating the session, and then change the path of the created session to the desired path. This is to avoid the race condition of when a session with a given path saves its state in the server database.

Note, I simulated slow kernels by adding a gen.sleep() in start_kernel.

I plan to backport this to 1.2.x since it involves no API changes and is a bug fix.

Slow start:

Switching during a slow start:

Selecting no kernel during a slow start:

Code changes

Add internal logic to session context to handle slow kernel behavior. Show filled icon for initializing status and in the toolbar. Update status bar handlers to always use display name and display status from the session context.

User-facing changes

Better indication of the status of slow starting kernels.

Backwards-incompatible changes

None

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[saulshanabrook]

I am moving to the next milestone so we have some more discussion on this before merging, but seems reasonable!

[blink1073]

I tried the resolve merge feature in Github. It results in a merge commit. I'll rebase and push.

[afshin]

👍

[blink1073]

@meeseeksdev please backport to 2.1.x

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout 2.1.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 44f161b1025acb1948599effdf55b28dcd9693c5

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #8174: Better handling of slow kernel startup'

4. Push to a named branch :

git push YOURFORK 2.1.x:auto-backport-of-pr-8174-on-2.1.x

5. Create a PR against branch 2.1.x, I would have named this PR:

"Backport PR #8174 on branch 2.1.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.