Possible bug with either websockets or access to widget in page about mux.jl HOT 6 CLOSED

Huh, thanks for the ideas, decided to check the stuck server side coroutine idea with a fresh restart but to no avail: same behavior, same "Error handling websocket connection" error message. Not sure if fully ruled out, but now betting the websockets error is the underlying issue, going to try digging into that more, will swing back here if I make any headway. Thanks again!

from mux.jl.

I think this at line 38 is the server side code which could benfit from an upgrade from read to readguarded. I suggest you open an issue on WebIO and then follow up with a pull request. Tag me if you would like a review.

I'm able to reproduce just as you say. I used Chrome to inspect the first page, button worked. Upon switching to the second page, the first one naturally closed down and produced the 'Error'. Which should be of no consequence at all since nobody cares what the coroutine does anymore. A new task/ coroutine is generated every time you load a new page.

function create_socket(req)
    sock = req[:socket]
    conn = WebSockConnection(sock)

    t = @async while isopen(sock)
        data = read(sock)

        msg = JSON.parse(String(data))
        WebIO.dispatch(conn, msg)
    end

    wait(t)
end

from mux.jl.

Hello, I do not know what goes wrong here, but the error message indicates that the client side (javascript) exits in an orderly fashion. This may happen if you close the window with the button in. It may just be how it should work, but with an old websockets.jl version, the server side read coroutine might just have got stuck forever.

This confuses the server side code. I do not know where it is, but it should read the wrbsocket using "readguarded" in order to avoid such messages.

Note I am just speculating and did not try your code.

from mux.jl.

Thanks hustf! As soon as the holiday season lightens up on me I'll take a closer look and open an issue with WebIO, probably tagging you in the pull request and/or the issue to be sure I clarified the issue correctly.

So if I'm understanding you right, that WebIO issue is likely separate from the behavior I described that appears to be a bug? Also good to know, with this lead perhaps I can make more headway on tracking down the bug.

Thanks again and happy holidays!

from mux.jl.

I was actually not reading properly. I can't reproduce the non-responsive behaviour. I get the error message whenever I close a page, but I can load both localhost:8000 and localhost:8000/page1. If I have several pages open at the same time and close one, the other ones are not affected. Perhaps you can report in more detail exactly what you do? Operating system, and which front-end?

from mux.jl.

Hey hustf, thanks for looking at this again, once you couldn't reproduce the non-responsive behavior I took another look at it. Remembering your comment on a potential WebIO issue, I found my WebIO was at 0.6.1 and I was able to update it to 0.7.0, and that seems to have fixed the issue?

I'm only a little mystified because I thought I had updated everything, and I don't see how I would have selectively updated Mux + Interact but not WebIO, resulting in some incompatibility, but that could be the case. For the record, I have a macbook running OSX 10.14 and Julia 1.02, and I was using Chrome.

Regardless, I better close this issue for now since it seems to be resolved with the combination of Interact.jl v0.9.0, Mux.jl v0.5.3, and WebIO v0.7.0. Thank you again! -Andrew

from mux.jl.