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

[Serge Aleynikov]

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