This commit uses the approach used in jupyter_server #191 first proposed
by David Brochart. This reduces code duplication and alleviates redundancy
relative to configurable options.
Also, the startup message now includes the version information.
Co-authored-by: David Brochart <david.brochart@gmail.com>
* Don't track API requests with `?no_track_activity=1` in the activity counter
allows external idle-culling scripts to avoid updating the activity counter
* Don't track kernel shutdown as kernel activity
this causes idle-kernel shutdowns to restart the idle-shutdown timer
user-requested shutdowns will still be tracked as api activity
* test ?no_track_activity=1 tracking
* Changelog for activity
instead of the monkeypatch we did to keep the backport patch small
requiring tornado 5 simplifies things a ton because tornado.concurrent.Future is asyncio.Future
Converted `MappingKernelManager.restart_kernel` to a coroutine so that
projects that take advantage of async kernel startup can also realize
appropriate behavior relative to restarts.
Eliminated the Kernel and Kernelspec handlers. The Websocket (ZMQ)
channels handler still remains. This required turning a few methods
into coroutines in the Notebook server.
Renamed the Gateway config object to GatewayClient in case we want
to extend NB server (probably jupyter_server at that point) with
Gateway server functionality - so an NB server could be a Gateway
client or a server depending on launch settings.
Add code to _replace_ the channels handler rather than rely on position
within the handlers lists.
Updated mock-gateway to return the appropriate form of results.
Updated the session manager tests to use a sync ioloop to call the
now async manager methods.
When kernels are culled, the kernel is terminated in the background,
unbeknownst to the session management. As a result, invalid sessions
can be produced that appear to exist, yet cannot produce a model from
the persisted row due to the associated kernel no longer being active.
Prior to this change, these sessions, when encountered via a subsequent
call to `get_session()`, would be deleted and a KeyError would be raised.
This change updates the existence check to tolerate those kinds of sessions.
It removes such sessions (as would happen previously), but rather than
raise a KeyError when attempting to convert the row to a dictionary,
it logs a warning and returns None, which then allows `session_exists()`
to return False since the session was removed (as was ultimately the
case previously).
Calls to `get_session()` remain just as before and have the potential
to raise `KeyError` in such cases. The difference now being that the
`KeyError` is accompanied by a message indicating the cause.
Fixes#4209
This allows slower contents managers to not block the event loop by allowing
more of their API to return futures.
Other usages of contents manager functions are already wrapped in maybe_future,
including a use of `file_exists` in contents/handlers.py
Recently I needed to troubleshoot kernel responses and found it helpful
to distinguish status types (busy vs. idle) - thought others might find
it useful as well.
Entries that previously appeared as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
```
will now appear as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
```
It's still (IMHO) unclear how the adaptation goes. Like does "adapting
to protocol X.Y.Z." mean the end-result is X.Y.Z or what you
got is X.Y.Z and it's X.Y.W after adaptation.
Although I'm unable to reproduce the issue, its a safe change to
prevent an AttributeError from occuring ('NoneType' object has no
attribute 'close'). The user that reported this is attempting to
launch a kernel and I believe the launch only partially completed
such that `kernel._activity_stream` did not get established.
(This occurred from Jupyter Enterprise Gateway where we deal with remote
kernel launches across resource-managed clusters, so things are a bit
more involved relative to kernel establishment.)
`exporter_map` is deprecated, so let's use the list of exporters fetched
from the installed entrypoints.
There's a supposed attribute `export_from_notebook` that should be set
to a friendly string name if the exporter should be exposed in the
front-end. However, the exporters defined in `nbconvert` don't have it
set, so I haven't used it to determine inclusion in the list. Instead,
I've used the entrypoint name as the friendly name, which looks like it
was the intention from the way they are named.
I ran the unit tests and tried starting up the notebook server and
accessing the API endpoint to verify the JSON looked correct.
It appears that the Windows backend of send2trash can't guarantee that
files won't actually be deleted. There are some hints that this happens
in particular when you delete a lot of data at once. So this returns to
refusing to delete folders unless they're empty (or contain only ipynb
checkpoints).
Closes gh-3631
Kevin Bates
Kerwin.Sun
sasaki takeru
Vibhanshu
Min ho Kim
Sylvain Corlay
Min RK
Johan Mabille
Frédéric Chapoton
Maxime Mouchet
Matthias Bussonnier
Michal Charemza
Maxim Vov
Sally Wilsak
Thomas Kluyver
M Pacer
Thomas Kluyver
Celina Kilcrease
Ashley Teoh