Handling Kernel Launches with Long Boot Times #5324
Replies: 3 comments 2 replies
-
@nicholaswold Sorry for the delay! First, the situation that you are running into is interesting. In particular, I would expect the kernel to eventually transition from starting to connected state once the To address this, we probably need to add a This is my preliminary analysis of this. Although I'm 🤔 about what caused the regression here since this behavior usually works. |
Beta Was this translation helpful? Give feedback.
-
@captainsafia I've got some time today to implement your suggested fix for Let me know if you have any ideas about the other issue I'm having about Nteract firing |
Beta Was this translation helpful? Give feedback.
-
@nicholaswold Thanks for digging into this and apologies for the delay.
I think this is fine. In the worst case scenario, we fire off the message but don't get a response back from the kernel (because something was wrong with it) and our "kernel not connected" logic kicks in. In the best-case scenario, we process the
Yep! This sounds sensible. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Hi, was hoping to get some guidance. I’m developing an application that deals with kernels that have longer boot times, and when I lazy-load a kernel the
launchWebSocketKernelEpic
successfully creates a new session on my Jupyter Server, which returns anexecution_state: "starting"
. This in turn triggers this check in thesendExecuteRequestEpic
, which sees that the execution state is "starting" and fails.What I’d like to do is have the
launchWebSocketKernelEpic
poll the sessions API until the kernel is ready, or to wait until akernel_info_reply
message is sent on the websocket and then pull the latest execution state. I don’t see a way to do either right now. Is there another mechanism to accomplish what I’m trying to do, or is this additional functionality I can contribute tolaunchWebSocketKernelEpic
?Beta Was this translation helpful? Give feedback.
All reactions