<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-12 17:02 GMT+02:00 Ingela Anderton Andin <span dir="ltr"><<a href="mailto:Ingela.Anderton.Andin@ericsson.com" target="_blank">Ingela.Anderton.Andin@ericsson.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi!<br>
<br>
I changed your server loop to:<br>
<br>
server_loop(ListenSocket, N) -><br>
    {ok, Socket} = ssl:transport_accept(<u></u>ListenSocket),<br>
    spawn(fun() -><br>
                  ok = ssl:ssl_accept(Socket),<br>
                  ssl:send(Socket, <<N>>),<br>
                  ssl:close(Socket)<br>
          end),<br>
    error_logger:info_msg("~w accepted\n", [N]),<br>
    server_loop(ListenSocket, N + 1).<br>
<br>
This will improve the situation. But increasing the number of concurrent clients can still cause a connectivity problem. When the<br>
server gets resource problems and sockets will be terminated already on tcp level. However so far I have not been able to find a bug only a load<br>
regulation problem.</blockquote><div><br></div><div>Typically what happens is that some clients will not get a connection on the </div><div><br></div><div>ssl:connect("localhost", 9999,  [], infinity)<br></div>
<div><br></div><div>but instead an {error, closed}. And it with that a pretty long delay for the remaining connections.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
<br>
Regards Ingela Erlang/OTP team - Ericsson AB<br>
<br>
<br>
On 05/09/2014 03:23 PM, Richard Carlsson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
Friday afternoon SSL fun: we're seeing long pauses where no client is<br>
getting any replies. See attached module. At first we thought it was a<br>
problem with lhttpc, but it turned out we could repeat the symptoms by<br>
making some simple concurrent ssl connections. (In our original case,<br>
the server was on another machine, and probably not using Erlang.)<br>
<br>
    /Richard<br>
<br>
<br></div></div><div class="">
______________________________<u></u>_________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org" target="_blank">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-bugs</a><br>
<br>
</div></blockquote><div class=""><div class="h5">
<br>
______________________________<u></u>_________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org" target="_blank">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-bugs</a><br>
</div></div></blockquote></div><br></div></div>