Closed robacarp closed 1 year ago
Also perhaps relevant, the Mozilla docs on SSE contain this warning. I don't think Crystal has any packaged HTTP2 support yet.
Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).
As well, I've just come across this. It appears that, since even after disconnect the loop still spins, when a reload event is triggered every open connection which is no longer tied to the browser throws an exception.
After the exception is thrown, the loop is obviously terminated. Which (accidentally) mitigates this bug at least a bit.
I witnessed this behavior just now. If I boot the server, and then trigger a recompile before loading a page with the browser, the first time I do the page is immediately reloaded.
Ah ok, I guess my implementation was a little naive when I thought just changing @should_restart
would work across all requests (fibers?). I did not notice this in my initial testing, but it's definitely a bug.
I was already aware of the limitations of SSE, but I know some people swear by it, so I thought it was worth keeping around.
I think my new implementation would be to store each request Context in a list, that when a reload should happen, it just pops each one off and runs the reload logic, then only break the loop when the context is closed. We'll see if that works.
@robacarp would you be willing to try out some of my fixes with your local setup?
Describe the bug
This could pretty easily fall into the simple territory of a bug we're okay living with.
In development mode, with
lucky watch --watcher=sse
, each time a browser is connected to the SSE server, a new loop is initiated withsleep 0.1
s.Simply clicking around on a site, navigating around pages, it's easy to get this loop spinning dozens of times.
I think this would cause an issue if the lucy dev server is running for a long time, and active development is refreshing the page over and over.
To Reproduce Steps to reproduce the behavior:
Screenshots/code
I was able to prove that this happens by modifying lib/lucky/tasks/watch.cr like this. After modifying the file,
rm bin/lucky.watch
and thenlucky dev
will compile the task on and run it.Very Verbose Output:
Versions (please complete the following information):