1

I have a comet application that bases on Erlang's gen_server and it works pretty well when used with different browsers but when I open multiple tabs of a page with the same browser, call to .yaws file takes a while to complete, with more than 6 tabs it doesn't even deliver messages until closing half of the tabs, though other browser are functioning normally and from the other browser are delivered almost instantly.

Explaining further

The application is too complex to add here to diagnose, Comet/long polling must be delaying the execution of the .yaws file but how??? It must has something to do with the yaws session, these are the tests I made... i opened 6 tabs on Opera, Chrome, Firefox plus their incognitos and signed in as 6 different users and it is functioning very well which I think gen_server is performing normally. Now I close all browser and reopen one browser plus its incognito, When I open 3 tabs on browser A and one tab on Browser B (which is incognito of the browser A) when I send a message from Browser B to A all tabs receive messages as expected but when I send message from Browser A to B it takes a while when I open 6 or more tabs messages are not sent even after 10 minutes, since long polling performs its tasks normally i think this, somehow causing the problem.

Update

I have been trying figure out this problem for days and finally I found the same issue in yaws examples.

Just open the link below on 7 or more tabs then check out the last opened tab as you go

=> http://yaws.hyber.org/server_sent_events.html

You will notice that the server doesn't respond as expected which is exactly the same problem I am having with long_polling

How do I overcome this problem?

  • 2
    It's difficult to answer this without knowing more details about your application, but have you tried writing a really simple `.yaws` file that just returns an HTML string, and seeing if that shows the same problem? Given that you mentioned `gen_server` I suspect you might be somehow serializing requests through a single process in your application. – Steve Vinoski Sep 29 '16 at 16:49
  • My comment exceeded its limitation so i included it into the question, Thank you. –  Sep 29 '16 at 19:15
  • 3
    Sorry, but even the new details don't help. The fundamental problem is that you're asking us to help analyze code for which we have no details. Your best bet is to try to reproduce this with a small example, since that way you're either going to find it's a problem in your code, or you'll be able to give us Yaws contributors something that shows a problem we need to fix. Note that we've supported long polling for years now and I've never heard of anyone having a problem like this. – Steve Vinoski Sep 30 '16 at 00:10
  • Okay, I am gonna reconstruct everything with minimum functionality and see what this is all about.. Thank you very much for your help)) –  Sep 30 '16 at 20:35
  • Hello, @SteveVinoski please check out the update section of the question. –  Oct 04 '16 at 19:50
  • Using Safari (Version 10.0 (11602.1.50.0.10)) I currently have 21 tabs open on that link, and all are operating exactly as they should. I stopped at 21 but more would work fine too. But with Chrome (Version 53.0.2785.116) then I see the behavior you see, with the 7th tab seeming to wait for data forever. According to [this bug report](https://bugs.chromium.org/p/chromium/issues/detail?id=12066), Chrome limits max connections per "group" to 6. Assuming you're using Chrome, this is a browser problem, not a Yaws problem. – Steve Vinoski Oct 05 '16 at 01:44
  • @SteveVinoski yes, that is the case... but unfortunately Firefox and Opera have the same connection limit. –  Oct 05 '16 at 07:43

1 Answers1

2

This isn't an issue with Yaws, but rather is a browser limitation on the number of server-sent events (SSE) connections you can have to a single IP address. Some browsers allow you to configure higher limits and some don't, which means if you're required to use SSE or long polling, you're pretty much stuck with those limits and will have to devise a way for your application to work within them.

You might consider using websocket instead, as browsers handle those connections differently and so they're not subjected to the same strict limits.

Community
  • 1
  • 1
Steve Vinoski
  • 19,847
  • 3
  • 31
  • 46