notebook: Asyncio error when opening notebooks

When I open a notebook from /tree, i get the following error in terminal:

  return _iterencode(o, 0)
[W 20:44:29.469 NotebookApp] Notebook NLP/3.02-obtain-model-results.ipynb is not trusted
ERROR:asyncio:Exception in callback <TaskWakeupMethWrapper object at 0x000001D12EB68DC8>(<Future finis...5ea"\r\n\r\n'>)
handle: <Handle <TaskWakeupMethWrapper object at 0x000001D12EB68DC8>(<Future finis...5ea"\r\n\r\n'>)>
Traceback (most recent call last):
  File "c:\users\work\miniconda3\envs\playground\lib\asyncio\events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
RuntimeError: Cannot enter into task <Task pending coro=<HTTP1ServerConnection._server_request_loop() running at c:\users\work\miniconda3\envs\playground\lib\site-packages\tornado\http1connection.py:823> wait_for=<Future finished result=b'GET /api/co...f5ea"\r\n\r\n'> cb=[IOLoop.add_future.<locals>.<lambda>() at c:\users\work\miniconda3\envs\playground\lib\site-packages\tornado\ioloop.py:688]> while another task <Task pending coro=<KernelManager._async_start_kernel() running at c:\users\work\miniconda3\envs\playground\lib\site-packages\jupyter_client\manager.py:336>> is being executed.

Desktop (please complete the following information):

  • OS: Windows
  • Browser Chrome
  • Version 92.0.4515.159

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Comments: 25 (14 by maintainers)

Commits related to this issue

Most upvoted comments

Hi @nissankarkifm - thanks for opening this issue.

I suspect this was introduced with the refactoring done in jupyter_client to use async methods for the synchronous KernelManager. The symptoms are the same as here but this is a bit beyond my knowledge level. Although the kernel/notebook appears to behave fine, there’s probably something hung up somewhere.

On the bright side, this issue can be avoided by configuring Notebook to run with its AsyncMappingKernelManager instead - which introduces a full async stack.

jupyter notebook --NotebookApp.kernel_manager_class=notebook.services.kernels.kernelmanager.AsyncMappingKernelManager

Or configure via the configuration file:

## The kernel manager class to use.
#  Default: 'notebook.services.kernels.kernelmanager.MappingKernelManager'
c.NotebookApp.kernel_manager_class = 'notebook.services.kernels.kernelmanager.AsyncMappingKernelManager'

We should probably consider making this (async kernel management) the default at some point. This would require jupyter_client >= 6.x.

Another option would be to cap jupyter_client < 7, but you’ll miss out on features exposed in jupyter_client 7+.

And a third option would be to switch to Jupyter Lab 3.x since it uses jupyter_server (which uses AsyncMappingKernelManager by default) instead of notebook for its server.

cc: @davidbrochart @maartenbreddels

Referring to this document. https://jupyter-notebook.readthedocs.io/en/stable/config.html
I run this command jupyter notebook --generate-config
"The Jupyter folder is in your home directory, ~/.jupyter. jupyter_notebook_config.py "

I’m experiencing the same issue. Using the configuration suggested by @kevin-bates works. (Python 3.9, OSX, Jupyter Notebook 6.4.4)

Under what circumstances is the default configuration expected to work out of the box? I think this issue should be re-opened and only closed when running Jupyter notebook works right away without having to override this option.

But given that the future of the Classic Notebook is taking a direction that will probably solve this issue (by using RetroLab for Notebook v7), I’m not sure we should try and fix Notebook<7.0.

@davidbrochart I definitely agree with you here! I actually hit this issue while upgrading jupyter_client to 7.x.x (we have currently pinned jupyter_client<7 which I’m working on removing). We are migrating to Lab/RetroLab and part of that process is getting all of the dependencies to their latest upstream version.

Moving to asynchronous kernel management is probably safer than not since that’s where the dev focus has been the last couple of years and JupyterServer has been using it since its inception (and on which Lab 3+ relies). So you’re essentially moving your “experience” closer to where you want to be eventually.

Also note that the import statement was moved into its current position in jupyter/jupyter_client#665, so we should probably run this past @SylvainCorlay as well.

Yeah I had noticed that and I wasn’t sure if it was a functional change, or just a housekeeping/linting/style thing (no commit message). But the important thing is that it wasn’t calling apply either. nest-asyncio doesn’t have any side effects on import.