Thanks for all the quick replies btw, y'all are awesome!
handleComms based on #6929. Suppose the following scenario:
widget-1, widget-2) of the same widgets are created (e.g. console), each with a different session pointing to two different kernels
widget-1) to use the session of
widget-2. This closes all comms that was registered by
widget-1since the new kernelconnection does not
registerCommTargetcall will be fenced by an if statement.
My question is suppose I want the kernel to talk to the two
widgets (now connected to the same kernel) either simultaenously or independently of each other, how would I send data over since
widget-2 now has no Comm associated with it?
handleCommsto keep both comms open?
Hi everyone, I'm running into an issue with extensions that I was hoping someone has a suggestion.
I am running jupyterlab inside a docker container, where I pre-install jupyterlab and all of the extensions as root user. When I run the docker container, I am running as a different user. In this case, the extensions fail to load in jupyterlab because the NPM cache folder is read-only for the current user, with "[...] are not valid NPM packages."
This is actually happening because jupyterlab calls "npm pack" on the extensions, requiring r/w access to the cache. If I chmod the cache first, everything works.
Is there a way to run jupyterlab where this wouldn't be an issue, i.e. it doesn't require r/w access to the original npm cache (that is owned by root on my system)?
@mc-allen have you tried install nodejs within a conda environment? if you have r/w access to the conda/envs dir then you should be fine in that case
yarn why <foo>in the
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?