<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/29/2015 09:56 AM, Adam Chlipala
wrote:<br>
</div>
<blockquote cite="mid:55E1BA2B.1020202@csail.mit.edu" type="cite">On
08/29/2015 01:16 AM, Ziv Scully wrote:
<br>
<blockquote type="cite">(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.
<br>
</blockquote>
<br>
Hm, I never noticed that before! It may be a concurrency bug in
the runtime system. I'll look into it further.
<br>
</blockquote>
<br>
I've looked into this issue, which was easy for me to reproduce. My
conclusion is that it is <i>not</i> a problem with Ur/Web!
Concurrency bugs are notoriously inconvenient to reproduce, but this
problem <i>always</i> appears for me with 6 Firefox tabs running
the chat demo, and it <i>never</i> appears for me with 5 tabs. The
magic number 6 suggests a straightforward explanation. Can anyone
guess? :)<br>
<br>
[SPOILER ALERT! Explanation revealed below. :)]<br>
<br>
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.<br>
<br>
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 <i>should</i> remove
most need for such things :]). It should be safe to have 3 tabs to
the same app per process, but no more.<br>
</body>
</html>