* 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.
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)
```
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.
* 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)