[erlang-questions] Building a Non-blocking TCP server using OTP principles

[Serge Aleynikov]

Despite the fact that aborting the application is also what's 
implemented in the tutorial, this may seem questionable to be "the only" 
reasonable recovery action as for some servers EMFILE can be a temporary 
condition.  Suppose there was a spike of short-lived client connections 
when the server might have hit the limit of file descriptors.  As some 
client connections disconnect, the server's gen_tcp:accept/1 call may 
recover automatically.  I could speculate that in selected cases it may 
be more expensive to failover/recover state of some applications in a 
node then to attempt several retries in a timely manner.

Serge

Claes Wikström wrote:
> Serge Aleynikov wrote:
> 
>>
>>                 {ok, Socket} = gen_tcp:accept(Listener)
>>
>> So you would need to monitor how many accept failures you got in the 
>> last several seconds and do some intelligent recovery.  This would 
>> complicate code by quite a bit.
> 
> 
> Checking the errors that can occur for accept, the only ones
> that apply are:
> 
>      [EMFILE]           The per-process descriptor table is full.
> 
>      [ENFILE]           The system file table is full.
> 
> 
> In either of these cases, there is really nothing good that can
> be done. I've just changed the default behavior of yaws to
> terminate the entire yaws application when accept actually fails.
> 
> When running the standalone server, the entire node will die and
> be restarted by heart.
> 
> This is a bit like trying to do something clever when malloc()
> fails - pondering on the issue for a couple of years eventually
> the only sane thing to do is exit(1), same thing with accept() here.
> 
> I think there are quite a few erlang/server apps that log the
> accept() error an retry - which is very bad if the error is e{n,m}file.
> 
> 
> /klacke