From 5e8ae7fcad5711c7d6fbaf8ebbedbc4a27002030 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Fri, 3 Dec 2021 15:47:48 +0100 Subject: [PATCH 1/6] Move kernel_info request on the control channel proposal --- 80-kernel-info/kernel-info.md | 40 +++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 80-kernel-info/kernel-info.md diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md new file mode 100644 index 00000000..9747093c --- /dev/null +++ b/80-kernel-info/kernel-info.md @@ -0,0 +1,40 @@ +# Send kernel\_info request on the control channel + +## Problem + +When connecting a new websocket to an existing kernel via the Jupyter server, if the kernel execution is +stopped on a breakpoint, the messages sent over the websocket get no reply. This is because when +establibshing a new websocket connection, the Jupyter server will send `kernel_info` requests to the kernel +and will prevent sending any other request until it receives a `kernel_info` reply. Since the `kernel_info` +request is sent on the shell channel and the kernel executino is stopped, it cannot reply to that request. + +## Proposed enhancement + +We propose to state in the Jupyter Messaging Protocol that the `kernel_info` request muter st be sent on the +control channel exclusively. + +### Impact on existing implementations + +There should not be any impact on the existing kernels, since the current specification states that any message +that can be sent on the shell channel could be sent on the control channel. + +The only impact of this change (beyond the protocol itself) is on the Jupyter Server, which must be updated +accordingly. + +## Relevant Resources (GitHub repositories, Issues, PRs) + +### GitHub repositories + +- [Jupyter server](https://github.com/jupyter-server/jupyter_server): the backend to Jupyter web applications +- [Jupyter client](https://github.com/jupyter/jupyter_client): Jupyter protocol client APIs +- [JupyterLab](https://github.com/jupyterlab/jupyterlab): JupyterLab computational environment + +### GitHub Issues + +- New websocket unable to communicate with kernel paused in debugging [#622](https://github.com/jupyter-server/jupyter_server/issues/622) +- [Debugger] Active sessions cause the kernel to deadlock on page refresh [#10174](https://github.com/jupyterlab/jupyterlab/issues/10174) + +### GitHub Pull Requests + +Nudge kernel with info request until we receive IOPub messages [#361](https://github.com/jupyter-server/jupyter_server/pull/361) + From fb5446aeabd0f6d4ab511c41ae8003810df4fc40 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Thu, 6 Jul 2023 17:58:25 +0200 Subject: [PATCH 2/6] Update to not remove the kernel_info request from the shell channel --- 80-kernel-info/kernel-info.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md index 9747093c..ddf61f84 100644 --- a/80-kernel-info/kernel-info.md +++ b/80-kernel-info/kernel-info.md @@ -4,22 +4,19 @@ When connecting a new websocket to an existing kernel via the Jupyter server, if the kernel execution is stopped on a breakpoint, the messages sent over the websocket get no reply. This is because when -establibshing a new websocket connection, the Jupyter server will send `kernel_info` requests to the kernel +establishing a new websocket connection, the Jupyter server will send `kernel_info` requests to the kernel and will prevent sending any other request until it receives a `kernel_info` reply. Since the `kernel_info` -request is sent on the shell channel and the kernel executino is stopped, it cannot reply to that request. +request is sent on the shell channel and the kernel execution is stopped, it cannot reply to that request. ## Proposed enhancement -We propose to state in the Jupyter Messaging Protocol that the `kernel_info` request muter st be sent on the -control channel exclusively. +We propose to state in the Jupyter Messaging Protocol that the `kernel_info` request can be sent on both the shell and the control channels. Although both channels supports the `kernel_info` message, clients are encouraged to send it on the control channel as it will always be able to handle it, while the shell channel may be stopped. ### Impact on existing implementations -There should not be any impact on the existing kernels, since the current specification states that any message -that can be sent on the shell channel could be sent on the control channel. +This JEP impacts kernels since it requires them to support receiving 'kernel\_info\_request' on the dontrol channel in addition to receiving them on the shell channel. -The only impact of this change (beyond the protocol itself) is on the Jupyter Server, which must be updated -accordingly. +It also has an impact on the Jupyter Server, which must be updated accordingly. ## Relevant Resources (GitHub repositories, Issues, PRs) From e093999bef7e428f555d3f65c919005518b55cc4 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 4 Dec 2023 17:00:27 +0100 Subject: [PATCH 3/6] Update 80-kernel-info/kernel-info.md Co-authored-by: gabalafou --- 80-kernel-info/kernel-info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md index ddf61f84..82d17134 100644 --- a/80-kernel-info/kernel-info.md +++ b/80-kernel-info/kernel-info.md @@ -14,7 +14,7 @@ We propose to state in the Jupyter Messaging Protocol that the `kernel_info` req ### Impact on existing implementations -This JEP impacts kernels since it requires them to support receiving 'kernel\_info\_request' on the dontrol channel in addition to receiving them on the shell channel. +This JEP impacts kernels since it requires them to support receiving 'kernel\_info\_request' on the control channel in addition to receiving them on the shell channel. It also has an impact on the Jupyter Server, which must be updated accordingly. From e584fdbe8fa1eadf1a91423dcf4faee2641f00f0 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 4 Dec 2023 17:25:33 +0100 Subject: [PATCH 4/6] Update 80-kernel-info/kernel-info.md Co-authored-by: gabalafou --- 80-kernel-info/kernel-info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md index 82d17134..35b226da 100644 --- a/80-kernel-info/kernel-info.md +++ b/80-kernel-info/kernel-info.md @@ -1,4 +1,4 @@ -# Send kernel\_info request on the control channel +# Support kernel\_info request on the control channel ## Problem From 3ec870b1be6fbb2ef83ad90a3dc0afaebf294924 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 4 Dec 2023 20:42:07 +0100 Subject: [PATCH 5/6] Update 80-kernel-info/kernel-info.md Co-authored-by: Zachary Sailer --- 80-kernel-info/kernel-info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md index 35b226da..5ce5c6d0 100644 --- a/80-kernel-info/kernel-info.md +++ b/80-kernel-info/kernel-info.md @@ -3,7 +3,7 @@ ## Problem When connecting a new websocket to an existing kernel via the Jupyter server, if the kernel execution is -stopped on a breakpoint, the messages sent over the websocket get no reply. This is because when +busy (e.g. long running cell) or stopped (e.g. on a breakpoint), the messages sent over the websocket get no reply. This is because when establishing a new websocket connection, the Jupyter server will send `kernel_info` requests to the kernel and will prevent sending any other request until it receives a `kernel_info` reply. Since the `kernel_info` request is sent on the shell channel and the kernel execution is stopped, it cannot reply to that request. From 46216b96e6bcd5a3182fd8afc7339856cade05c6 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 4 Dec 2023 20:42:56 +0100 Subject: [PATCH 6/6] Update 80-kernel-info/kernel-info.md Co-authored-by: Zachary Sailer --- 80-kernel-info/kernel-info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/80-kernel-info/kernel-info.md b/80-kernel-info/kernel-info.md index 5ce5c6d0..d6ec8b79 100644 --- a/80-kernel-info/kernel-info.md +++ b/80-kernel-info/kernel-info.md @@ -16,7 +16,7 @@ We propose to state in the Jupyter Messaging Protocol that the `kernel_info` req This JEP impacts kernels since it requires them to support receiving 'kernel\_info\_request' on the control channel in addition to receiving them on the shell channel. -It also has an impact on the Jupyter Server, which must be updated accordingly. +It also has an impact on the Jupyter Server. For example, the reference implementation of Jupyter Server will attempt to send a a `kernel_info` request on both channels and listen for a response from _either_ channel. Any response informs the UI that the kernel is connected. ## Relevant Resources (GitHub repositories, Issues, PRs)