comments
This commit is contained in:
parent
501b5b09f6
commit
79a160b760
2 changed files with 60 additions and 0 deletions
|
@ -0,0 +1,22 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2024-12-03T18:41:08Z"
|
||||
content="""
|
||||
Tried in chromium, also seeing it block sometimes, though not always, on
|
||||
page loads.
|
||||
|
||||
This seems rather similar to this old bug involving the same software:
|
||||
<https://github.com/yesodweb/wai/issues/146>
|
||||
But not I think quite the same, because that was caused by
|
||||
a long delay between clicks, and this happens when clicking immediately.
|
||||
|
||||
The browser's network console shows a few ms for all resources to load,
|
||||
except the page itself which for some reason takes a log time.
|
||||
|
||||
tcpdump shows that chromium does not send a request for that page until
|
||||
many seconds after the click. The response to the request is immediate.
|
||||
|
||||
Before that point there is only some SYN/ACK traffic. Which looked a bit
|
||||
weird maybe.
|
||||
"""]]
|
|
@ -0,0 +1,38 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2024-12-03T20:13:35Z"
|
||||
content="""
|
||||
Looking at the network inspector, it seems more likely a given click stalls
|
||||
when there are multiple long polling requests ongoing at the same time
|
||||
(which show as "pending").
|
||||
|
||||
So on a hunch, I disabled javascript in chromium. No more hangs.
|
||||
|
||||
I suppose maybe chromium has a small pool of connections to the web server,
|
||||
and if all of those get blocked up doing long polling, and if it doesn't
|
||||
cancel those when navigating away from the page that made the long polling
|
||||
request, it could block?
|
||||
|
||||
But why wouldn't it cancel them? The requests were made by the page it's
|
||||
navigating away from. Maybe it cancels them only once it's loaded the new
|
||||
page.
|
||||
|
||||
I do think that's it though. When I open 2 tabs both to the webapp,
|
||||
a request in one tab can be stalled, and pressing escape in the other tab,
|
||||
when it cancels the long polling requests, will unstall it.
|
||||
|
||||
Amazingly, chromium is limited to 6 concurrent connections per server, with
|
||||
no way to configure it! And the front page of the webapp opens several
|
||||
long polling connections.
|
||||
|
||||
In firefox, by comparison, the network inspector shows the long polling
|
||||
connections apparently disappear when navigating to a new page. But, there
|
||||
is a similar problem, when opening 2 tabs to the webapp, one can stall,
|
||||
due to the long polling connections open by the other tab.
|
||||
|
||||
So, I think the solution to this will either need to involve some change
|
||||
to the long polling javascript, if there is some way to make chromium
|
||||
cancel the request when navigating away... Or it would need to replace the
|
||||
long polling with something else entirely.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue