[BUG] Bokeh app does not display in notebook cell the first try on Chrome OS Linux; net::ERR_CONNECTION_REFUSED

[Ricyteach]

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

import yaml

from bokeh.layouts import column
from bokeh.models import ColumnDataSource, Slider
from bokeh.plotting import figure
from bokeh.themes import Theme
from bokeh.io import show, output_notebook

from bokeh.sampledata.sea_surface_temperature import sea_surface_temperature

output_notebook()

def bkapp(doc):
    df = sea_surface_temperature.copy()
    source = ColumnDataSource(data=df)

    plot = figure(x_axis_type='datetime', y_range=(0, 25),
                  y_axis_label='Temperature (Celsius)',
                  title="Sea Surface Temperature at 43.18, -70.43")
    plot.line('time', 'temperature', source=source)

    def callback(attr, old, new):
        if new == 0:
            data = df
        else:
            data = df.rolling('{0}D'.format(new)).mean()
        source.data = ColumnDataSource.from_df(data)

    slider = Slider(start=0, end=30, value=0, step=1, title="Smoothing by N Days")
    slider.on_change('value', callback)

    doc.add_root(column(slider, plot))

    doc.theme = Theme(json=yaml.load("""
        attrs:
            Figure:
                background_fill_color: "#DDDDDD"
                outline_line_color: white
                toolbar_location: above
                height: 500
                width: 800
            Grid:
                grid_line_dash: [6, 4]
                grid_line_color: white
    """, Loader=yaml.FullLoader))

show(bkapp) # notebook_url="http://localhost:8888" 

Stack traceback and/or browser JavaScript console output

GET http://localhost:39325/autoload.js?bokeh-autoload-element=1003&bokeh-absolute-url=http://localhost:39325&resources=none net::ERR_CONNECTION_REFUSED

Screenshots or screencasts of the bug in action

[bryevdv]

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.

[Ricyteach]

I'm willing to help, just let me know what to do. Perhaps posting a repo branch I can install and run would help?

[bryevdv]

@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)

[bryevdv]

@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:

bokeh/bokeh/io/notebook.py

Lines 479 to 497 in 5cf81e4

	server.start()
	if callable(notebook_url):
	url = notebook_url(server.port)
	else:
	url = _server_url(notebook_url, server.port)
	logging.debug("Server URL is %s" % url)
	logging.debug("Origin URL is %s" % origin)
	from ..embed import server_document
	script = server_document(url, resources=None)
	publish_display_data({
	HTML_MIME_TYPE: script,
	EXEC_MIME_TYPE: ""
	}, metadata={
	EXEC_MIME_TYPE: {"server_id": server_id}
	})

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.

[Ricyteach]

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.

[bryevdv]

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

[Pinous]

Hello to you both,

Do you have any improvements ?