Notebook App doesn't reconnect to a running kernel

[ptwobrussell]

My understanding from a chat with Brian Granger was that I should be able to lose a connection with an existing kernel (such as would be the case in closing a web browser that's running against a remote server when a kernel is busy with the "*" indicator by a cell), and ipynb would reconnect to that kernel when I re-open the notebook. This doesn't appear to be the case, so I wanted to ask for clarification on whether or not it's a bug or it's just not a feature at this point.

Test case to reproduce is a notebook cell with the following in it:

import time
while 1:
    print "X"
    time.sleep(1)

[minrk]

What happens if you do this after re-opening:

1. interrupt kernel
2. execute a new cell

?

[minrk]

If you actually have no connection to the kernel, the interrupt will never happen, and/or the new cell execution will never be submitted. If you are connected, then it will be interrupted, and the new cell will be submitted.

[ptwobrussell]

When I come back to the notebook, I don't see any new "X"s getting printed. When I interrupt the kernel and then execute a different cell, it executes fine, but still no new "X"s getting printed (which I suppose wouldn't happen anyway since the kernel was just interrupted)

Should be easy enough to try out on your end as well.

My use case is that I'd like to be able to have a long-running cell (which might literally take days to execute) and be able to close/re-open the web browser. Otherwise, I'm not sure how you could use ipynb for anything long-running in which you don't have a constant connection

[ellisonbg]

I mentioned this last night, but you probably didn't catch/understand it:

When you disconnect from a kernel by closing your browser, the kernel
continues to run, but you lose the ability to get the future output of the
cells that have been submitted for execution. You can still reconnect but
to get output you will have to submit new cells. This is not ideal, but we
honestly don't know how to solve this problem with our current design.

On Thu, Aug 29, 2013 at 12:55 PM, Matthew A. Russell <
notifications@github.com> wrote:

When I come back to the notebook, I don't see any new "X"s getting
printed. When I interrupt the kernel and then execute a different cell, it
executes fine, but still no new "X"s getting printed (which I suppose
wouldn't happen anyway since the kernel was just interrupted)

Should be easy enough to try out on your end as well.

My use case is that I'd like to be able to have a long-running cell (which
might literally take days to execute) and be able to close/re-open the web
browser. Otherwise, I'm not sure how you could use ipynb for anything
long-running in which you don't have a constant connection

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4138#issuecomment-23518645
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[ellisonbg]

Ironically, the output is actually coming back to your browser after you
reopen, but the notebook web app doesn't know which cell the output goes
with so it discards it. We could improve that, but we are not sure what we
would do...

On Thu, Aug 29, 2013 at 1:11 PM, Brian Granger ellisonbg@gmail.com wrote:

I mentioned this last night, but you probably didn't catch/understand it:

When you disconnect from a kernel by closing your browser, the kernel
continues to run, but you lose the ability to get the future output of the
cells that have been submitted for execution. You can still reconnect but
to get output you will have to submit new cells. This is not ideal, but we
honestly don't know how to solve this problem with our current design.

On Thu, Aug 29, 2013 at 12:55 PM, Matthew A. Russell <
notifications@github.com> wrote:

When I come back to the notebook, I don't see any new "X"s getting
printed. When I interrupt the kernel and then execute a different cell, it
executes fine, but still no new "X"s getting printed (which I suppose
wouldn't happen anyway since the kernel was just interrupted)

Should be easy enough to try out on your end as well.

My use case is that I'd like to be able to have a long-running cell
(which might literally take days to execute) and be able to close/re-open
the web browser. Otherwise, I'm not sure how you could use ipynb for
anything long-running in which you don't have a constant connection

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4138#issuecomment-23518645
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[ptwobrussell]

@ellisonbg - Ah, I see now. I misunderstood. I thought that you would just lose the output that would have been sent to your browser while it was closed but once you re-connected, you would start seeing output again when the kernel "reconnects"

It sounds like for my case in which I just have one long-running cell, once I close the browser, there is just no way to recover that output unless I do a little extra work to have it logged to a file on disk that I could monitor (which should work fine.) All I really need to do is keep an eye on it to see that progress is happening in a calculation.

I'll leave it to you guys to close this or to use it as a reference point as an enhancement for what would be a really cool feature enhancement.

[ellisonbg]

Let's close this one, but open another with a more accurate description of
the problem.

On Thu, Aug 29, 2013 at 1:20 PM, Matthew A. Russell <
notifications@github.com> wrote:

@ellisonbg https://github.com/ellisonbg - Ah, I see now. I
misunderstood. I thought that you would just lose the output that would
have been sent to your browser while it was closed but once you
re-connected, you would start seeing output again when the kernel
"reconnects"

It sounds like for my case in which I just have one long-running cell,
once I close the browser, there is just no way to recover that output
unless I do a little extra work to have it logged to a file on disk that I
could monitor (which should work fine.) All I really need to do is keep an
eye on it to see that progress is happening in a calculation.

I'll leave it to you guys to close this or to use it as a reference point
as an enhancement for what would be a really cool feature enhancement.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4138#issuecomment-23520279
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[michaelaye]

A link to the new one with more accurate descriptions would be helpful. Which one is it? There are quite several ones that have reconnection as a topic?

[michaelaye]

That would be #4140 I guess.

[michaelaye]

Brian, your description seems to imply that newly created cells should be able to execute and receive output after a reconnect? That does not seem to work for me.

[mohammedyunus009]

When I come back to the notebook, I don't see any new "X"s getting printed. When I interrupt the kernel and then execute a different cell, it executes fine, but still no new "X"s getting printed (which I suppose wouldn't happen anyway since the kernel was just interrupted)

Should be easy enough to try out on your end as well.

My use case is that I'd like to be able to have a long-running cell (which might literally take days to execute) and be able to close/re-open the web browser. Otherwise, I'm not sure how you could use ipynb for anything long-running in which you don't have a constant connection

I too have the similar use uses like yours , But for those things jupyter is not useful , Better off to regular python files and kernel , and use screen tool for Linux