Our team has made some modifications and developments to Jupyter, and one of the requirements is the use of “restart” to manage updates for resources. We want to modify the post method of the KernelActionHandler class in the notebook/services/kernels/handlers.py file (branch: 6.5.x, line 82), so that when the action branch is “restart”, the “restartkernel” method will be called. However, due to some reasons, an exception might be thrown. In the exception, we want to call the listsessions function of the session manager to get the sessions, and then delete them based on their IDs. The code is as follows:
It seems that we cannot retrieve IDs using array indexing, which is shown in line 94 of the code. I would like to know if my method of calling is correct. If it is correct, does that mean the problem of array index out of bounds is caused by the returned empty array when failing to retrieve sessions? Please kindly help me to answer this, thank you very much!
Hello @ycsong1212 - thank you for the post and welcome to the community!
I think the issue you’re running into is that you’re not yielding
sm.list_sessions() as it is a coroutine. However, you should not assume that the first session in the list is the session associated with this kernel that is failing to restart. Instead, you would likely need to walk the list of sessions and compare [“kernel”][“id”] to
kernel_id to determine the appropriate session to delete.
That said, I would recommend performing your session cleanup in a separate request (assuming you’re issuing the restart action from your application). The concern being that you might run into reentrancy issues or things of that nature, not necessarily now, but perhaps down the road as this breaks the directional flow that is
Let me explain why we are looking for the first session and deleting it. We use enterprise-gateway to manage the lifecycle of the kernels and we strictly limit the number of kernels to 1. Therefore, having only one kernel is the expected behavior. Our first concern is to confirm if the list_sessions method returns a list and if our call is getting the session_id correctly.
As for why we need to manually delete the session, it is because we want to start the kernel with new resource requirements, but the conditions are not met, so we need to manually clear the kernel. Therefore, we did not use a separate request to perform session cleanup. So, we want to know the correct way to obtain the session_id and execute the delete session operation. If there is an issue with our method of calling, could you please provide a correct way to get all the sessions and retrieve the session_id from them? Thank you very much.
Did adding the
yield statement help?
We use enterprise-gateway to manage the lifecycle of the kernels and we strictly limit the number of kernels to 1. Therefore, having only one kernel is the expected behavior. Our first concern is to confirm if the list_sessions method returns a list and if our call is getting the session_id correctly.
I believe you should still assert that the session entry you do have is indeed associated with the current kernel, but that’s up to you.
If there is an issue with our method of calling, could you please provide a correct way to get all the sessions and retrieve the session_id from them?
The call you are making is how you would acquire the session (although some checking should be performed, as we’ve discussed). I just don’t agree with deleting the session within a failed restart operation. In addition
SessionManager.delete_session() calls the on the
MultiKernelManager to shutdown the kernel, so I think some confusion could ensue when your client goes to delete the session in the normal control flow (likely a
404). This just feels sketchy to me.
The code snippets you provide appear to be from Notebook, rather than Jupyter Server. Is that code running in the Enterprise Gateway process or the notebook server that is forwarding requests to the EG server? The reason I ask is because EG really doesn’t use sessions unless the client application chooses to interact with EG via the
sessions api, rather than the
kernels api (like the notebook and jupyter_server gateway clients do).