Should I report this as a bug then…?
Sure, but I should be up front and state realistically that if there is an issue somehow tied to specific hardware then there may nothing we can do.
Can you successfully load the failing URL from the console log manually?
I understand. SinceI have replicated it on two different models of Acer Chromebook I doubt it is hardware specific-- they are very different hardware (manufactured a couple years apart). Am working on replicating it on another brand to confirm it is all Chromebooks.
Sorry I was using hardware a bit loosely. Offhand in this case is seems Chrome on ChromeOS is the common denominator (unless I’ve misunderstood the results)
Correct, that seems to be the case. I’ll just point out that Chromebooks are a very widely used platform and getting more use every day. They are pretty much all I do this kind of work on anymore (though I’m far from a professional developer).
I pasted the URL below into the omnibar and it loads what looks like a javascript file just fine.
http://localhost:43899/autoload.js?bokeh-autoload-element=1003&bokeh-absolute-url=http://localhost:43899&resources=none
AH HA! A new clue: when I navigate to that URL in a separate tab and come back to the notebook, this appears below the cell that is not rendering the Bokeh app correctly:
WARNING:tornado.access:404 GET /favicon.ico (::1) 1.97ms
EDIT: This SO question seems to be related to this but I have no idea how to fix it. EDIT: I guess this message could be unrelated to my problem though-- maybe the error is related to the other tab not having a favicon at the top *shrug*.
The favicon message is harmless. Bokeh server doesn’t currently have any support to provide favicons, but that’s nothing that will stop an app from rendering (and is commonly seen in both wrt to Bokeh and in general). The issue is truly (and specifically) the ERR_CONNECTION_REFUSED on the autoload URL.
If you paste the URL in the navbar and repeatedly force reload does it always load, or does ever fail intermittently? If it always succeeds then perhaps there is a race condition and the connection is refused because the endpoint serving the URL is not running yet. But I don’t know why that would only be the case on Chrome on ChromeOS.
I think you have figured it out— yes, if I run all the cells the output does not initially appear and the error occurs. However, if I right click on the notebook GUI and select “reload frame”, everything works. So it must be asking for that URL before it is available…?
What happens if you run this code manually right after a failure?
from bokeh.io.notebook import run_notebook_hook
from bokeh.io.state import curstate
notebook_url = "localhost:8888" # or whatever it really is
run_notebook_hook('jupyter', 'app', myapp, curstate(), notebook_url)
Edit: missed your earlier reply. Seems plausible, I think trying the above experiment is also still valuable
When I do that it spits out the same error in the console log, and if I do it repeatedly, it just does it over and over.
Oh wait CORRECTION it is the same error but a different port for the failing URL every time.
Oh, right. It’s still generating a new random port downstream from that call. I’ll have to try and construct a test that hits the existing port, but it may it may have to involve you editing the installed Bokeh source.
@Ricyteach you should be able to pass a port=12345 keyword arg to the run_notebook_hook call (use the actual port value from the failed console message)
Oh ok-- integer and not a string, right?
Yes, integer
---------------------------------------------------------------------------
OSError Traceback (most recent call last)
<ipython-input-5-35d7c2d71572> in <module>
4 notebook_url = "localhost:8888" # or whatever it really is
5
----> 6 run_notebook_hook('jupyter', 'app', bkapp, curstate(), notebook_url, port=45237)
~/venvs/dxf-test/lib/python3.7/site-packages/bokeh/io/notebook.py in run_notebook_hook(notebook_type, action, *args, **kw)
296 if _HOOKS[notebook_type][action] is None:
297 raise RuntimeError("notebook hook for %r did not install %r action" % notebook_type, action)
--> 298 return _HOOKS[notebook_type][action](*args, **kw)
299
300 #-----------------------------------------------------------------------------
~/venvs/dxf-test/lib/python3.7/site-packages/bokeh/io/notebook.py in show_app(app, state, notebook_url, port, **kw)
472 origin = _origin_url(notebook_url)
473
--> 474 server = Server({"/": app}, io_loop=loop, port=port, allow_websocket_origin=[origin], **kw)
475
476 server_id = uuid4().hex
~/venvs/dxf-test/lib/python3.7/site-packages/bokeh/server/server.py in __init__(self, applications, io_loop, http_server_kwargs, **kwargs)
393 http_server_kwargs['ssl_options'] = context
394
--> 395 sockets, self._port = bind_sockets(opts.address, opts.port)
396 self._address = opts.address
397
~/venvs/dxf-test/lib/python3.7/site-packages/bokeh/server/util.py in bind_sockets(address, port)
58
59 '''
---> 60 ss = netutil.bind_sockets(port=port or 0, address=address)
61 assert len(ss)
62 ports = {s.getsockname()[1] for s in ss}
~/venvs/dxf-test/lib/python3.7/site-packages/tornado/netutil.py in bind_sockets(port, address, family, backlog, flags, reuse_port)
172
173 sock.setblocking(False)
--> 174 sock.bind(sockaddr)
175 bound_port = sock.getsockname()[1]
176 sock.listen(backlog)
OSError: [Errno 98] Address already in use
And here is the console error that happens at the same time, if it’s of any use:
Couldn't process kernel message TypeError: Cannot read property 'trim' of undefined
at output (eval at append_javascript (outputarea.js:763), <anonymous>:47:39)
at Kernel._handle_output_message (kernel.js:1197)
at proxy (jquery.min.js:10502)
at Kernel._handle_iopub_message (kernel.js:1224)
at Kernel._finish_ws_message (kernel.js:1016)
at kernel.js:1007
(anonymous) @ kernel.js:1008
Promise.catch (async)
Kernel._handle_ws_message @ kernel.js:1008
proxy @ jquery.min.js:10502
The trim message is not coming from Bokeh, I’m not sure what it is but it seems common with the notebook in general. (Note that it shows up even in the working cases)
What I am trying to test is whether the the app can be displayed if some delay is added. Unfortunately the simple routes I thought of also try to do all the server setup again, as seen above, so that’s not helpful (because it will fail with “address already in use”, etc). I think testing this will be a bit more involved. I will have to look in to getting you some detailed instructions, but it probably won’t be today. In the mean time, a GH issue is probably the best place to move to.
Gotcha. I’ll post an issue.