Connect to existing kernel on subsequent accesses #515
Comments
|
Every time a user connects (including when they revisit the page), a brand new kernel is instantiated. So voila already only runs the python code once. If instead, you're talking about sharing one kernel amongst multiple users, how would you manage concurrency of widgets? if one person moves a slider, does it have to sync for everyone? What if person A is entitled to access some data that person B is not entitled to, how do you enforce that for everyone? I think the per-user segregation is one of the most valuable features of voila, and not something to be changed. |
|
Sorry for the misunderstanding. I don't want to change the default behavior. As you said the python code is executed on every access in a different kernel. It would be nice to have the option to share a kernel among multiple accesses. |
|
I added a bit of code (<10 lines) to handler.py in order to cache the rendered notebook. This way a kernel is only started once on the first notebook access. On subsequent accesses only the rendered notebook is returned. If someone is interested in this, I am willing to submit a merge request. The behavior could be controlled by a configuration flag |
|
Another place where connecting to an existing kernel could make sense is for the voila preview in JupyterLab (in a single user setup). This could be useful especially for debugging a voila dashboard without starting a new kernel on every change. But jupyter-widgets/ipywidgets#1218 would indeed still be relevant, as the changes would not be reflected in the preview panel (IFrame). The preview would then be "another view" of the notebook. |
|
Also related: #95 |
I'm having the same issue as you. I have 1 notebook, with multiple users hosted in AWS/ECS. Using the Notebook cells, every widget loads just fine, however, the Voila (used as an extension) is always trying to access old kernel that was running and doesn't know that there's a new kernel being used somehow, and gives me 404 errors "Kernel doesn't exist". The only way to bypass this is to refresh the page with cache clearing (e.g. Cntrl + Shift + R) then Voila loads fine. Can you please tell me if you've found a proper way to fix this? |
|
now that jupyter-widgets/ipywidgets#3195 has been fixed can this be looked at again? I'd also very much like this! In particular for the use case of controlling a physical device (e.g. arduino) remotely. ipywidgets is by far the easiest way to create browser based a gui for somethign like this. So it would be very exciting to be able to (without any webdev knowledge) easily make a nice GUI that can be controlled remotely. Presuming that jupyter server could manage password access for me then I think there would be an enormous number opportunities in science labs (and home DIY things) for using something like this. However, in those cases there can only ever be one kernel that is connected to the device at a time so starting a new kernel on each connection won't work. @jtpio are there other concerns to be dealt with before attempting to implement something like this? |
|
I think @mariobuikhuizen added some nice tools that can connect to existing
kernels, for instance to implement a popout window, based on
jupyter-widgets/ipywidgets#3195
<jupyter-widgets/ipywidgets#3195>
Can you share some info/links/examples here mario?
(from mobile phone)
Op di 15 feb. 2022 04:46 schreef Ian Hunt-Isaak ***@***.***>:
… now that jupyter-widgets/ipywidgets#3195
<jupyter-widgets/ipywidgets#3195> has been fixed
can this be looked at again?
I'd also very much like this! In particular for the use case of
controlling a physical device (e.g. arduino) remotely. ipywidgets is by far
the easiest way to create browser based a gui for somethign like this. So
it would be very exciting to be able to (without any webdev knowledge)
easily make a nice GUI that can be controlled remotely. Presuming that
jupyter server could manage password access for me then I think there would
be an enormous number opportunities in science labs (and home DIY things)
for using something like this. However, in those cases there can only ever
be one kernel that is connected to the device at a time so starting a new
kernel on each connection won't work.
@jtpio <https://github.com/jtpio> are there other concerns to be dealt
with before attempting to implement something like this?
—
Reply to this email directly, view it on GitHub
<#515 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANPEPIBQN27HLCQDHY5RFDU3HEBVANCNFSM4KGVKO6A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
This is meant as a way to show a widget or composition of widgets in a separate browser window/tab (for the same user): https://github.com/mariobuikhuizen/ipypopout, but it may serve as an example on how to connect to an existing kernel when you know the kernel-id. (The current version still has a workaround that can be removed if jupyter-widgets/ipywidgets#3195 is used) But in the case of @ianhi I think you would want to control having a single kernel from the server. |
|
This would be very useful, in particular when certain resources (e.g., GPUs) are limited. |
Is it possible to configure voila in a way, that it does not run the python code again on subsequent browser accesses but connects to the existing kernel and reloads the widget state?
I have a Notebook containing jupyter widgets that control a C-API, which I can only instantiate once. With JupyterLab and Jupyter Notebook the widget state is saved in the notebook. This allows on a second access where the widgets still interact with the existing kernel. It would be awesome if voila could behave similar.
The text was updated successfully, but these errors were encountered: