On 08/29/2015 09:56 AM, Adam Chlipala wrote:
On 08/29/2015 01:16 AM, Ziv Scully wrote:
(2) Sometimes doing "many" (order of 6) channel operations slows down
the server considerably, causing all requests to stall for a bit. The
stall isn't permanent, but often after the stall resolves, some small
subset of the messages don't make it to their recipients. The clients
who missed messages might still receive future messages but will
never receive the ones they missed. I found that something similar
occurs with the official Chat demo (try joining the same channel in
~8 tabs in quick succession), so I don't think the issue is specific
to my app. Has anyone run into this before? I messed with the .urp
file a little bit but nothing helped.
Hm, I never noticed that before! It may be a concurrency bug in the
runtime system. I'll look into it further.
I've looked into this issue, which was easy for me to reproduce. My
conclusion is that it is /not/ a problem with Ur/Web! Concurrency bugs
are notoriously inconvenient to reproduce, but this problem /always/
appears for me with 6 Firefox tabs running the chat demo, and it /never/
appears for me with 5 tabs. The magic number 6 suggests a
straightforward explanation. Can anyone guess? :)
[SPOILER ALERT! Explanation revealed below. :)]
6 is the default number of connections that Firefox will open to a
single server. When you open 6 tabs, every tab has one open connection
to the server, waiting for new chat messages. Clicking the "send"
button in any tab triggers a new connection, for a POST request asking
to send the message. Firefox dutifully obeys its limit of 6 connections
at once to a server, queueing up your new message until after some
current connection closes. But now we have a quasi-deadlock, as those
connections are open waiting for the message! Eventually, they time out
as part of the normal heartbeating protocol, at which point your new
message finds itself at the head of the queue and actually goes out.
That's why the problem only manifests as delays, rather than a dead stop
for the remaining life of your open tabs.
So, in summary, the problem seems to be an artifact of your testing
strategy, which doesn't simulate real client usage in that it involves
too many tabs connecting to the same server. I bet you could avoid the
issue by using different browser processes at once, which is easiest for
me to do, in my environments, by running Firefox and Chrome
simultaneously (bonus points for testing cross-browser compatibility,
though Ur/Web /should/ remove most need for such things :]). It should
be safe to have 3 tabs to the same app per process, but no more.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
