Fix activity tracking and nudge issues when kernel ports change on restarts #482
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change adds the ability for the
ZMQChannelsHandler
and activity watching logic to determine if ports have changed when restoring connections and restarting kernels, respectively.By determining that ports have changed during restarts, the
MappingKernelManager
can also restart the activity monitor since it listens on the iopub channel. This will preserve proper functionality for culling behaviors as well as allow the "nudge" functionality to determine the kernel is busy - bypassing the time-based attempts to send/recieve a kernel-info request.ZMQChannelsHandler.open()
makes use of the fact that the kernel's ports have changed when restoring a connection (which essentially consists of loading state from previously recorded buffers). Prior to this change, the nudge functionality within this branch would use the kernel's previous iopub channel to listen for replies and time out. It will now use the kernel's current iopub channel when port changes are detected.I made an attempt to write a test for this but this requires buffering to occur and I'm not certain what else the front end is doing. However, use of the tests's
NewPortsMappingKernelManager
andNewPortsKernelManager
subclasses make introducing port-changes on restarts rather simple and I decided to retain this class's use in the tests in cases other port-related issues are encountered.With these subclasses, this issue can be reproduced by running the following command:
You will also need to change the result of the new internal method
MappingKernelManager._get_changed_ports()
to returnNone
to disable port-change detection.Resolved #481