New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Be able to receive cell output from a remote kernel after reconnecting #4140
Comments
Do you condone +1 comments? (Sorry if not). |
+1 (sorry if not...) |
There is a "half" of a work-around based on the ipycache extension. For example: %load_ext ipycache
%mkdir -vp ipycache
import time A cell can be "decorated" by the %%cache ipycache/test_long
i = 1
while i<30:
print '{}, '.format(i),
time.sleep(1)
i+=1 The browser can be closed |
+1 |
1 similar comment
+1 |
This would be incredibly useful for creating reports or tests |
+1, didn't actually realise this is a limitation of the notebook and lost some output that I incorrectly assumed would be waiting for me when I rejoined my server... Any chance a core developer could weigh in and give a brief idea as to how feasible this is to fix? Just to confirm I'm not missing something, whilst this goes unresolved the notebook is not good for running long jobs on remove servers that you can then rejoin to check state. As a concrete example, a user is at their office workstation and is just finishing up a notebook that will take some hours to run. User leaves the office and on the train later on gets a (sporadic) SSH port forward back to the office workstation. They tweak the notebook and get it finished - they hit run. Connection will bounce in and out for the next few hours - later on the user will rejoin the SSH port forward and have no output waiting for them. |
This is tough. Really. We need to move the M part of MVC to the server and get synchronization with client, so an architecture which is more MC-MVC with the dash being the network. |
So, I guess @jabooth 's work-flow could only be solved today with writing any and all results to disk, correct? |
If the kenel still have the value then you can re-display it.
close browser, wait 10 sec, open browser,
You can probably alo do things with Futures also. |
@Carreau, I am willing to help get this working, as this would be a big help to my coworkers and I who are used to working with screen for remote jobs. You say this is being worked on. Is there a fork or branch I could take a look at? Thanks. |
Thanks a lot for the proposal. Hum, right now that will be though, but let me make a quick recap of future plan.
Depending on what you want to work on there are plenty to do. Even if you are just better at communicating that we are, and know a bit about our future plan, I should probably make a blog post that details more what we are doing :-P |
What if the web UI could just show some kind of raw console with the output being sent from the kernel, even if it doesn't know what cell that output should go into? Obviously that's not the full long-term solution, but at least it would alleviate a critical usability issue for those of us using the notebook to monitor long-running jobs. |
#7087 should at least lay down the basics for that where there are hooks to receive this output. We still don't know exactly what to do with the output, core team is divised half half on "the right thing'" to do. |
This is dirty, DIRTY hack! But if you want to be able at least see the progress output (not cached though), put this code in your custom.js $([IPython.events]).on('app_initialized.NotebookApp', function(){
IPython.notebook.events.on('received_unsolicited_message.Kernel', function(evt, data) {
cells = IPython.notebook.get_cells();
ncells = cells.length
idx = ncells-1
for (var i = ncells-1; i >= 0; i--) {
if (cells[i].get_text() != ""){
idx = i;
break;
}
}
cells[idx].output_area.handle_output(data)
});
}); It will append the output from the kernel to the last non-empty code cell. Not nice, but works for me... |
+1 |
11 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
1 similar comment
+1 |
I think if the notebook could have another V layer to capture all the progress data. The browser will interact with this layer instead of raw python kernel. The problem could be solved. (Like a long running proxy browser on your server) This doesn't seem to be a small surgery. But another idea I have is more like frontend point of view. If the jupyter notebook supports server rendering someday using react/angular2.js/etc... then this problem will be automatically solved. This feature is very important, since jupyter notebook is extremely popular among machine learning development workflow. Some algorithm training programs could last a couple of days. |
Yes @benbbear, you seem to have came up with roughly one of the long-time planned architecture. The extra question we still haven't solved is how to build real-time collaboration on top of that. Currently if you used Python you can use |
Great to see RT collaboration is on the road map. Maybe the collaboration could be easier if the proxy layer is websocket-enabled instead of just http? Just my rough idea. Use Asynchronous computing to hold intermediate result, this is genius... 👍 |
+1 |
3 similar comments
+1 |
+1 |
+1 |
If you can restrain from just posting +1 that woudl be great. You can or use emojis on the issue, github added them for that, as you can sort issues by number of +1 Emojis. Also if you just like to subscribe to the issue there is the "subscribe" button on the right. We are aware of the issue and are doing our best. +1 ing won't make things faster. though reviewing open PRs and trying to write simple patches for issue tagged as "Need contributor" can free us some time to actually work on this :-) We'll also be happy to teach you jupyter internals to get new contributors ! Also at some point the issue probably need to be migrated to jupyter/notebook as this track only core IPython issue now. Thanks ! |
+1 (SCNR) A connection drop today also made me fall into that trap :-/ I guess even at the moment something on server side must be able to notice that no client is connected anymore. Can't it in such cases modify the ipynb file directly? (Like an auto-saver server side fail-over loop in case no client is reachable.) Obviously a proper, cool async solution that also allows multi-player edit would be awesome, but after nearly 4 years, maybe a simpler solution first? |
+1 |
+100000000000 |
This actually seems to happen now, though. When I leave the notebook open, put my laptop to sleep while there's output coming (even matplotlib images), then later resume my laptop, re-initiate the connection and reconnect to the kernel, I receive the output that happened while the connection was gone. There's actually two flags controlling this that I had to increase:
|
@lucasb-eyer You mean jupyter notebook or jupyterlab? It seems to be somewhat working in jupyterlab, but not perfectly. Regrading your settings, could you justify that your settings relevant? |
Jupyter notebook, I didn't even know about jupyterlab 😄 Yes, the settings are relevant because when the notebook reconnects, all missed messages come streaming in, which kicks-in these rate-limits. Before adjusting the values as above, I only got the first bunch of missed messages upon reconnect exactly because of these rate-limits. Now they are large enough so that I usually get everything I've missed. That's in my typical workflows and tasks, at least. The notebook actually pointed me to those settings when starting to drop messages. |
Which version of notebook are you using? I couldn't get this working on 4.0.6 version. |
Uhm, seriously? |
Hello Lucas, thanks for your suggestion.
I am using Jupyter Notebook 5.4.0. I put the three options you were
mentioning in the config file.
Unfortunately, I also couldn't get this working. I will update to 5.4.1 to
test the same version you have.
Best regards,
Franco
…On Fri, May 25, 2018 at 6:35 PM, Lucas Beyer ***@***.***> wrote:
Uhm, seriously? 4.0.6 is 3 years old! I'm using 5.4.1 in all that I
described above.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4140 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADmYKzmINkC0vF6AIHd-We1_5G-_CB0Qks5t2DLAgaJpZM4A8uyX>
.
|
@lucasb-eyer I guess this only works when you reopen the browser, see jupyter/notebook#1647:
So this fix does not really apply for a remote use case where you want to close the browser tab. |
@CYHSM Your statement is self-contradicting, I guess you wanted to write
right? Because in that case, I think you are right: I always put my laptop on standby and thus the notebook stays in the same tab. |
Any update on this, please? |
+1, this feature would be extremely useful |
+1 |
Hi, has this been looked at yet? |
Yes (jupyterlab/jupyterlab#15448). The notebook codebase is no longer in IPython repository, instead it resides in https://github.com/jupyterlab/jupyterlab and https://github.com/jupyter/notebook. Closing in favour of issues in the repositories where the relevant code is actually in: |
Once your browser disconnects from the kernel running on a remote notebook server, there's no way to recover the output once the notebook reconnects to the kernel. My understanding is that even though the output is actually shipped back to the browser, it's just unable to be sent to the right cell for display. If you are using IPython Notebook for long-running computation in a cell, the ability to re-connect and get cell output from the point of reconnection forward would be nice to have.
The text was updated successfully, but these errors were encountered: