Open Ricyteach opened 4 years ago
Noting that The only thing that I have been able to not rule out so far is some sort of race condition where the client code tries to make the initial HTTP request before the endpoints are set up. I'm not sure why it would only reliably seem to affect Chrome on ChromeOS (and I don't have a Chromebook to test with).
Perhaps putting the request in a next-tick callback on the IOLoop could force a reliable (good) ordering. Experimentation will be needed.
I'm willing to help, just let me know what to do. Perhaps posting a repo branch I can install and run would help?
@Ricyteach That's fantastic, let me think about some possible tests and I will reply here with some instructions and or links (hopefully by the end of the week)
@Ricyteach I've been a bit swamped but I at least wanted to expand on my thoughts in case you would like to experiment locally. My basic thought is that there is simply a race condition between the start and end of this block of code:
Specifically, server.start
just adds Bokeh callbacks for app endpoints to the existing notebook Tornado event loop, and then the publish_display_data
outputs JS code that tries to connect to the app endpoint. My best (only) guess is that on some platforms the JS connection request can execute before the endpoints are actually up and running.
So one idea would be to try to wait some arbitrary delay before start and finish. I don't think a blocking time.sleep
woudl work since that would just time-shift issue without changing anything important (but could be worth a quick try). Another idea would be to try and install execute the publish_display_data
in a next-tick callback on the IOLoop, on the idea that that must necessarily happen after the server.start
work has finished.
Sorry for the delay but I should have time to investigate this later in the week or this weekend. I am very interested in getting this fixed since I'm trying to write a bokeh app and my chromebook has become pretty much my primary dev machine, and it's becoming tiresome to have to reload the frame over and over every time I make a change in Jupyter.
That's great @Ricyteach happy to have any and all help on your schedule, please let me know how I can help support your investigation
Hello to you both,
Do you have any improvements ?
Hello, I first brought this up over at discourse and after some initial investigation Bryan advised me to go ahead and open an issue.
Problem replicated using two different models of Chrome OS machines (on the Linux beta) with the following:
bokeh 2.1.0 python 3.7.1, 3.7.3, 3.8.1, and 3.8.3 jup notebook 6.0.3 Chrome OS 83.0.4103.97 and 83.0.4103.112 Chrome browser 83.0.4103.97 and 83.0.4103.112 NOTE: only replicates using Chrome browser ON Chrome OS. Does not replicate using Chrome on Windows, or alternative browser on Chrome OS (e.g., I installed Konquerer and the problem does not replicate)
Description of expected behavior and the observed behavior
Expected behavior is for the app to display in the notebook cell as usual (notebook served locally on 8888), but it does not display and the console log reports a net::ERR_CONNECTION_REFUSED (example of full console error printed below).
However after the error has occurred, if I right-click in the output cell area for the problem cell and select "Reload frame", the app displays correctly (NOTE: this "Reload frame" does not appear to be the same thing as Ctrl+r, i.e., reloading the whole page). I am wondering if this is evidence of some kind of race condition at work.
Complete, minimal, self-contained example code that reproduces the issue
Stack traceback and/or browser JavaScript console output
Screenshots or screencasts of the bug in action