* 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
* provide some top level comments
* implement buffering of messages on last dropped connection
- buffer is per-kernel
- session_key is stored because only a single session can resume the buffer and we can't be sure
- on any new connection to a kernel, buffer is flushed.
If session_key matches, it is replayed.
Otherwise, it is discarded.
- buffer is an unbounded list for now
* restore actual zmq channels when resuming connection
rather than establishing new connections
fixes failure to resume shell channel
* hookup restart callbacks in open
instead of in `create_stream`, which is not called on reconnect
* improve handling of restored connections in js
- dismiss 'connection lost' dialog on reconnect
- set busy status on reconnect (if not busy, idle will come soon after via kernel_ready)
large stream outputs cause much more problems than image output
this does open up to large HTML and/or displayed text output,
but those seem to behave well more often than they don't.
Sylvain Corlay
Min RK
Johan Mabille
Kevin Bates
Maxim Vov
Matthias Bussonnier
M Pacer
Thomas Kluyver
Thomas Kluyver
Michael Heilman
Kyle Kelley
dhirschf
Peter Parente
Peter Parente
Kevin Bates