[Ur] Unsafe GET and slow message passing

[Adam Chlipala]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150905/582362a7/attachment.html>