-
-
Notifications
You must be signed in to change notification settings - Fork 531
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
Rewrite server extension to run Panel applications in kernels #3763
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3763 +/- ##
==========================================
- Coverage 84.21% 83.70% -0.51%
==========================================
Files 213 214 +1
Lines 31016 31267 +251
==========================================
+ Hits 26121 26173 +52
- Misses 4895 5094 +199
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I can't see there is a high probability of someone spinning up lots of kernels unless they have Jupyter lab for ever running. But maybe in a Jupyter Hub environment this could become an issue? Our JupyterHub closes the session/ server after 1 hour of inactivity though. |
43c74be
to
58ffeca
Compare
58ffeca
to
9479a6a
Compare
This PR reimplements the panel preview server extension in its entirety to execute Panel applications in custom kernels. It does this by querying the notebook for its kernel spec and then requesting a kernel from Jupyter. In this kernel it executes the following:
Internally the
PanelExecutor
creates a bokehServerSession
and connects it to a JupyterComm
. ThePanelHandler
will then serve the result ofexecutor.render()
and a request to open a WebSocket will be sent to thePanelWSHandler
. This in turns forwards any messages it receives via thekernel.shell_channel
to theComm
. This way we proxy any WS messages being sent to and from the server to the kernel.The major benefit of this is:
Drawbacks:
ToDo