- connect iopub first (tiny effect on the race!)
- docstrings, log details
- resolve immediately if kernel is busy, rather than setting up timeouts, futures
- use gen.with_timeout instead of separately managed timeout
- use gen.multi to wait for both futures instead of duplicated check in each handler, third Future
- add various cancel conditions (sockets closed, kernel stopped, etc.)
This commit updates the super usage. Because Python 2 is not supported
anymore, super usage can be updated such that super is called without
any arguments in the default case where super is called with the class
name and self.
Note that all usage of super has not been updated - a few cases which
smelled funny have been ignored.
KernelManager's last_activity attribute is added following the instance's
creation. Culling (independently) uses this attribute and should ensure
it exists prior to its use, else skip the culling check for that instance.
Fixes#5345
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.
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.)
After analyzing various leaked items when running either Notebook or
Jupyter Kernel Gateway, one item that recurred across each kernel
startup and shutdown sequence was the a zmq socket instance associated
with the iopub port. The leaked instance occurs because the activity
monitor and normal port creation logic both call `create_iopub`.
Although this ens up creating a _wrapper_ around the same port, the
object (i.e., wrapper) created by the activity monitor is leaked. By
setting the kernel manager's `_activity_stream` member to `None` when
the kernel is shutdown, cleanup of the iopub wrapper object will take
place.
- start asyncio loop explicitly in notebook thread (tornado 4 starts per-thread loops automatically, asyncio doesn’t)
- remove unsupported ‘io_loop=‘ arg in websocket test
application runs fine with tornado 5, just a few test bits needed updating
* tornado 5: PeriodicCallback loop arg will be removed
PCs are always run with the current eventloop,
which is what the explicitly passed loop always is for us already
* Don't double-close socket & stream
closing stream closes the socket
* remove now-inaccurate comment
martinRenou
Kevin Bates
Zachary Sailer
Min RK
Sylvain Corlay
Sai Rahul Poruri
Pinar Kavak
sasaki takeru
Johan Mabille
Maxim Vov
Matthias Bussonnier
M Pacer
Thomas Kluyver
Thomas Kluyver