Or should I force the new KernelConnection associated with widget-1 to handleComms to keep both comms open?
@TK-21st - right now, you'd have to explicitly force the new kernel connection to handle comms. Just be aware that there can be subtle problems with using the same comm from two different clients, where, for example, one client may shut down a comm the other client is using.
For example, if client A has a specific comm handler registered, but client B does not, a message to open a comm for that comm handler will open the object in client A, but the spec demands that client B close the comm channel, which shuts down the comm object in the kernel. No notification is sent to client A about the closure, so the result is that client A has a comm channel to nowhere
@jasongrout Thanks for the clarification, I got it to work by forcing
handleComms = true. I do understand the potential issues that come with that, could you may suggest a better alternative if two clients are to share a kernel?
Previously this was done by re-routing the content of
commMsg callback to the new client in browser. But then it's not immediately clear to me how the client with the comm can know which other client to route the data to. Or similarly, how the new client knows where to get data from in run-time
TypeError: request to http://localhost/api/kernels?1590921821770 failed, reason: connect ECONNREFUSED 127.0.0.1:80FetchError: request to http://localhost/api/kernels?1590921821770 failed, reason: connect ECONNREFUSED 127.0.0.1:80- I find strange that the server is launched on port 80 (should not be possible for non root user) - Tried as root but I receive anyway the same error.
~/.jupyterand built with
yarn build:packages && yarn build:utils && yarn build:testutilsthen ran
yarn test. Most prolly something on my env but good if one can confirm the js test services run fine on his local env.
Any restriction for max value for "c.MappingKernelManager.cull_idle_timeout" ?
I didn't find in the document for any limitations or in stack overflow?
Today we have in our: /etc/jupyter/jupyter_notebook_config.py
c.NotebookApp.shutdown_no_activity_timeout = 8 60 60
c.MappingKernelManager.cull_idle_timeout = 8 60 60
c.MappingKernelManager.cull_interval = 20 * 60
We want to increase the timeout to 24-48 hours.
Any known issues/risks/limitations?
AnyThreadEventLoopPolicybut it broke jupyter
colorwas a function that just returned a string, but was a hint to the editor to highlight the string argument as a color.
chunksfor the contents api is documented anywhere? https://github.com/jupyterlab/jupyterlab/blob/caaecc573bd511521fce73b0aa718ea4264fc016/packages/services/src/contents/index.ts#L90 It doesn't seem to be included here: https://jupyter-notebook.readthedocs.io/en/stable/extending/contents.html