Voila: Connect to existing kernel on subsequent accesses

Created on 14 Jan 2020  路  6Comments  路  Source: voila-dashboards/voila

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.

Most helpful comment

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 https://github.com/jupyter-widgets/ipywidgets/issues/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.

All 6 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.
As I said this is already possible with default Jupyter Lab and Notebook. The case of propagating changes to each frontend is still an open issue (https://github.com/jupyter-widgets/ipywidgets/issues/1218). In the current implementation the changes are not synced.
The scenario you mention is a bit overkill for me as I would be perfectly happy without synced widgets or a user based access policy.

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 --cache-notebooks=True

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 https://github.com/jupyter-widgets/ipywidgets/issues/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.

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 --cache-notebooks=True

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?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tomnewg picture tomnewg  路  7Comments

choldgraf picture choldgraf  路  5Comments

janfreyberg picture janfreyberg  路  6Comments

jeiche picture jeiche  路  8Comments

johnjarmitage picture johnjarmitage  路  6Comments