emfile error

[Chandrashekhar Mullaparthi]

I dont know how to avoid this limitation. We frequently come across this
problem but in a different way. Sometimes Java clients setup lot of
connections and leave it to the garbage collector to clear the connections.
This is very slow in Java and the server runs out of file descriptors. And
mnesia crashes!!! The way we get around this is to limit the number of
connections from each host, increases the number of file descriptors per
process using the ulimit command on UNIX. It'll be interesting to hear
possible solutions.

Chandru

> -----Original Message-----
> From: Rick Pettit [mailto:rpettit@REDACTED]
> Sent: 3 December 2001 21:44
> To: erlang-questions@REDACTED
> Subject: emfile error
> 
> 
> 
> I have an erlang process which runs as a concurrent TCP server.  It
> functions as a gateway between non-erlang processes and 
> Erlang processes.
> 
> The server listens on a well-known TCP port and spawns a 
> child to handle
> each request.  The child will parse TCP input and forward the 
> request via
> Erlang messaging to the appropriate Erlang server, waiting 
> for a response
> (another Erlang message) before responding over TCP and 
> closing the TCP
> connection.
> 
> The problem is that when the server is hit hard the clients receive an
> emfile error, which I understand could be the result of a UNIX process
> (the erlang node, in this case) running out of descriptors.
> 
> Is this a known problem with concurrent erlang servers?  I would not
> expect this same error if my server was in C and it fork()'d 
> children, as
> each child would then have its own descriptor table and would 
> have very
> few entries in it (stdin, stdout, stderr, TCP client socket).
> 
> I wonder if the entire node appears to the host OS as a single process
> (perhaps one with many threads), in which case I would expect 
> this problem
> with most any concurrent server.
> 
> Please forgive me if I am doing something silly or am missing some
> fundemental coding convention that would have alleviated this problem.
> 
> Rick
> 



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.