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.
- 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
Kevin Bates
Min RK
M Pacer
Thomas Kluyver
Thomas Kluyver
Michael Heilman
Kyle Kelley
dhirschf
Peter Parente
Peter Parente
Kevin Bates
Sylvain Corlay
Diego Mesa
Jonathan Frederic