jupyter server doesn't work with large javascript assets about webio.jl HOT 14 CLOSED

😢 I think IJulia sets this limit when you do notebook(), can you try Conda/deps/usr/bin/jupyter notebook?

from webio.jl.

I started this jupyter from the command line (Not by calling the notebook function). 😟

from webio.jl.

Related: JuliaLang/IJulia.jl#528 and https://github.com/JuliaLang/IJulia.jl/blob/397d190ae68c6d61425b0239733090cd93450875/deps/build.jl#L102

Can you try these?

from webio.jl.

I tried jupyter notebook --NotebookApp.iopub_data_rate_limit=2147483647, but that didn't help...

from webio.jl.

This is really unfortunate. Maybe if you downloaded PlotlyJS using npm you can do code splitting.

from webio.jl.

Thanks for the tip about code splitting. Because plotly.js updates frequently (every couple of weeks) I'd like to avoid solutions that don't allow me to just grab the latest plotly-latest.min.js and get to work.

Do you have any ideas why we are seeing this via the asset server while it hasn't come up in other settings?

from webio.jl.

I think I'm totally misunderstanding the problem here, I think it has nothing to do with what I pointed to above. It seems while writing the response, something is setting a Content-Length header which doesn't simply match with the actual content's length.

I tried downloading https://cdn.plot.ly/plotly-latest.min.js into an assets directory to reproduce this issue, but I couldn't. It just worked. On Chrome+Linux.

from webio.jl.

The error could probably be traced starting from this line which prints the message in tornado python web framework -- https://github.com/tornadoweb/tornado/blob/master/tornado/http1connection.py#L451

from webio.jl.

I'm getting the same error in Firefox on Ubuntu when loading the WebIO components javascript, which unfortunately makes WebIO unusable in jupyter lab with Firefox.

On jupyter lab startup, the server prints:

[E 19:39:20.968 LabApp] Uncaught exception GET /pkg/WebIO/webio/dist/webcomponents-lite.min.js (127.0.0.1)
    HTTPServerRequest(protocol='http', host='localhost:8838', method='GET', uri='/pkg/WebIO/webio/dist/webcomponents-lite.min.js', version='HTTP/1.1', remote_ip='127.0.0.1')
    Traceback (most recent call last):
      File "/usr/local/lib/python3.5/dist-packages/tornado/web.py", line 1545, in _execute
        self.finish()
      File "/usr/local/lib/python3.5/dist-packages/tornado/web.py", line 1019, in finish
        self.request.finish()
      File "/usr/local/lib/python3.5/dist-packages/tornado/httputil.py", line 418, in finish
        self.connection.finish()
      File "/usr/local/lib/python3.5/dist-packages/tornado/http1connection.py", line 452, in finish
        self._expected_content_remaining)
    tornado.httputil.HTTPOutputError: Tried to write 19536 bytes less than Content-Length

and in the javascript console in my browser, I see:

Loading failed for the <script> with source “http://localhost:8838/pkg/WebIO/webio/dist/webcomponents-lite.min.js”.

Visiting that URL on localhost shows that the contents of webcomponents-lite.min.js has been truncated to 2^16 characters.

Switching to Chrome resolves the problem.

from webio.jl.

More info: visiting the /pkg/WebIO/webio/dist/webcomponents-lite.min.js URL in Chrome still triggers the HTTPOutputError and results in an empty response in the browser. But, weirdly, WebIO.jl just works anyway in Chrome, with no errors. I'm baffled.

from webio.jl.

Chrome doesn't need webcompoments polyfill.. it shouldn't even be trying to load the file on chrome..... I think maybe I'm supposed to call some super class method in the tornado server plugin....

I'm unable to reproduce this locally, so will have to debug this through you two...
https://stackoverflow.com/questions/28146700/writing-the-content-length-header-to-the-client-from-the-server-in-tornado?rq=1

Found this which talks about the error message.

In your case does it always say 19536 bytes less than Content-Length

Or does the number change?

from webio.jl.

Thanks for your help! Yes, it's always exactly the same message. Specifically, the number of bytes less than content-length is always exactly 19536, which is exactly the number of bytes in that js file minus 2^16. The browser, likewise, always receives exactly the first 2^16 characters of the file. So it seems that the server is always sending exactly 2^16 bytes and then erroring out with 19536 bytes left in the file.

from webio.jl.

I was also wondering if there was some issue with a maximum length of a single line, but adding newlines throughout the file does not help.

from webio.jl.

I'm starting to understand more of what's going on here, although I don't have a solution yet. What's happening under the hood is that WebIO's JuliaPackageAssetServer uses tornado's StaticFileHandler internally. The way StaticFileHandler works is by chunking files into 64kB blobs: https://github.com/tornadoweb/tornado/blob/b9e2da2046c521c8d71988f03307db36809282af/tornado/web.py#L2630 When serving the WebIO assets, however, only the first chunk is actually transmitted. That is, this loop, which should be iterating through all the chunks, only executes its first iteration: https://github.com/tornadoweb/tornado/blob/b9e2da2046c521c8d71988f03307db36809282af/tornado/web.py#L2472

I suspect this has something to do with the fact that StaticFileServer.get() is a coroutine, so perhaps JuliaPackageAssetServer.get() should also be a coroutine which yields from that coroutine?

from webio.jl.