Prior to this change, the request timeout for a Gateway request
was synchronized with KERNEL_LAUNCH_TIMEOUT only if KLT
was greater. However, the two are closely associated and KLT
should be adjusted if the configurable request_timeout is greater.
This change ensures that the two values are synchronized to the
greater value. It changes the two configurable timeouts to default
to 40 (to match that of KLT) and removes the 2-second pad,
since that wasn't helpful and only confused the situation.
These changes were prompted by this issue: jupyter/enterprise_gateway#792
This commit uses the approach used in jupyter_server #191 first proposed
by David Brochart. This reduces code duplication and alleviates redundancy
relative to configurable options.
Also, the startup message now includes the version information.
Co-authored-by: David Brochart <david.brochart@gmail.com>
Since there's a 6.0.3 release brewin', I thought we should bump
the minimum version of jupyter_core from 4.6.0 to 4.6.1. The
latter has an edge case to the slew of secure_write issues that
would be very annoying if NB 6.0.3 didn't upgrade to that version.
The edge case is to tolerate the owner-execute bit on the connection
file, which occurs when RUNTIME_DIR resides on certain filesystem
types (e.g., CIFS).
The bug:
When
- the user login for the first file with a token and want to change his/her password
- and if the folder `~/.jupyter` (`jupyter_config_dir()`) does not exist
then the jupyter server will raise a `FileNotFoundError` exception and return a 500 error.
This change tries to fix this bug by ensure the folder exist so that the `config_file` can be opened.
`gateway_request` in `gateway.manager` raises `tornado.web.HTTPError` exceptions,
but the callers, such as `GatewayKernelManager.get_kernel`, catch
`tornado.httpclient.HTTPError`, instead of `tornado.web.HTTPError`.
Therefore, the callers can not handle exceptions during gateway interactions.
This causes that, for example, when Jupyter Enterprise Gateway culled a kernel
by idle timeout, the gateway manager can not handle the kernel's absent appropriately.
As a result, notebook users see ambiguous "Kernel Error" and can not restart
the kernel or start a new kernel.
