[erlang-questions] A possible problem with the canonical listener idiom

[Steve Vinoski]

+1 to everything Serge says. Also, unless I'm missing something, I
don't see how the original code can work with active set to anything
but false anyway, since it never sets the controlling process for the
connected socket to that of the spawned handler.

--steve

On 1/1/09, Serge Aleynikov <saleyn@REDACTED> wrote:
> I believe that canonical examples you refer to are not the real-life
>  guidelines one should use in writing production-grade TCP servers.  The
>  problem you found is indeed real when you are dealing with serious load.
>   However if you read documentation of inet:setopts/2, at the end it
>  clearly states that the use of {active, true} is not advised for high
>  traffic conditions as it doesn't have flow control.  Consequences can be
>  rather drastic - race conditions, message queue overflow leading to high
>  CPU utilization of the emulator and a subsequent crash.  Therefore,
>  every writer of a network server dealing with serious load (whether it
>  involves TCP or UDP transport) should pay very close attention to the
>  value of 'active' socket setting.  It seems to me that {active, false}
>  in the listening/accepting socket and  {active, once} is the most
>  preferable choice as it gives one the ability to have the "mailbox"
>  message delivery non-blocking semantics as Erlang OTP programmers are
>  accustomed to.  This example is illustrated here:
>
>  http://trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles
>
>  Regards,
>
>  Serge
>
>
>  John Haugeland wrote:
>  > I'm not really 100% on this, but I think there might be a race condition
>  > in the canonical example listener under serious load which can lead to
>  > the initial packet(s) from an active or once-active socket being
>  > delivered to the accepting process rather than the handling process.
>  > I've documented what I believe the problem is, and how to fix it
>  > (including a standard fix in my utility library scutil, under the name
>  > standard_listener), here:
>  >
>  > http://fullof.bs/a-better-erlang-tcp-listening-pattern-addressingthe-fast-packet-loss-problem
>  >
>  > I would appreciate commentary.  If I'm wrong, please let me know.
>  >
>  >
>
> > ------------------------------------------------------------------------
>  >
>  > _______________________________________________
>  > erlang-questions mailing list
>  > erlang-questions@REDACTED
>  > http://www.erlang.org/mailman/listinfo/erlang-questions
>  _______________________________________________
>  erlang-questions mailing list
>  erlang-questions@REDACTED
>  http://www.erlang.org/mailman/listinfo/erlang-questions
>