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.
- reset counter on status: idle (avoids Run All running into limits)
- fix rate measurements to exclude messages not sent due to rate limiting
- fix formatting of rate-exceeded messages, tweak text a bit
- after pausing output, don't resume sending until rate has dropped 20% below limit, to avoid rapid back & forth across the limit