[JUPYTER DEPENDENCY][WIP] Add support for async kernel management

[kevin-bates]

Updated RemoteKernelManager's methods to coroutines and derive from jupyter_client's AsyncIOLoopKernelManager. In addition, RemoteMappingKernelManager derives from notebook's AsyncMappingKernelManager.

Converted various time.sleep() to yield gen.sleep() which enables tornado to "slice-out" to a different request. As a result, converting confirm_remote_startup() and handle_timeout() to coroutines was key.

Updated the response socket to use asyncio non-blocking sockets.

NOTE: Installation of this PR requires that BOTH related Jupyter Client 428 and Notebook 4479 PRs be merged. Once merged, we need to update our dependencies to depend on those versions - thus the bracketed values in the title.

NOTE 2: With this change the kernel management class used in Kernel Gateway is skipped! The class provides support for single-instance kernels used for the http-mode. As a result, support that mode from EG users will not work. Since we want to copy the web handlers from JKG into EG to accommodate things like HA support, cutting out http-mode is probably something we should do anyway since it doesn't really fit in our wheelhouse.

Fixes #86
Fixes #592

EDIT: The PRs referenced above have been updated to reflect the recent PRs submitted that use a subclass-based approach. Please see those PRs for a description the class hierarchy.

[esevan]

gr8 change LGTM 👍
Just a question, #587 says we're not gonna support python2 any longer, but should we use coroutine instead of async?

[kevin-bates]

@esevan - great question.

I'm hoping this change needs to can be back-ported to our 1.x branch - so that's one reason for not moving to the 3.x constructs. In addition, we probably shouldn't make that switch until Notebook and jupyter_client have done the same. I don't know if using async/await in one class will work with coroutine/yield in a superclass or vice versa. Do you know if that works?

For the time being, I believe we should continue using backward compatible code until we know we're going to not go back or the benefit of using the more native constructs is critical to the implementation's success.

The most important aspect to this PR is that the dependent PRs get merged AND are part of releases, so we can then update our dependencies in setup.py.

Thanks.

[kevin-bates]

The dependent areas of jupyter_client and notebook are in the process of getting reworked due to compatibility issues of the original PRs. A subclassed approach is being looked at and we should have good information by the end of this week. Stay tuned.

[kevin-bates]

I've updated the description (along with the referenced PRs) to reflect the subclassed based approach introduced in the referenced PRs.

The other thing to note is that we probably lose support for http-mode that comes from JKG since we're now skipping those classes. Should we decide otherwise, then we'll need to create async-related classes in JKG and update EG to reference the async parent. Not a big deal, but since we're thinking about implementing our own web handlers for HA support, it might be good separate the two.

[kevin-bates]

If anyone wants to take things for a spin, here's a zip of whl files with relative changes in jupyter_client, notebook and enterprise_gateway.

AsyncKernelManagement-wheels.zip

I'll update the EG image shortly.

[kevin-bates]

An EG image built on the referenced PRs can be found at elyra/enterprise-gateway and pulled via the following:

docker pull elyra/enterprise-gateway:dev_async

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/scalable-enterprise-gateway/2014/2

[kevin-bates]

Due to the switch to using subclasses this PR is being closed in favor of #794. A new release of jupyter_client contains the necessary changes, so once the notebook PR is merged, we should be able to merge #794.