I agree with the other things that have been recommended.
As far as the file descriptors go, IIRC the Racket VM uses the old
asynchronous I/O system in Linux that limits to FD_SETSIZE files
(which is normally very large, but still a fixed number.) It is
unlikely you are hitting that.
As far as
Following up on this -- what's the max number of open file descriptors that
Racket allows? We're seeing some lingering ones (trying to trace the source,
but wondering if this is the problem).
We are also getting a lot of ssl error reports of the forms
Connection error: ssl-accept/enable-break:
On Wed, Sep 7, 2011 at 5:38 AM, Kathi Fisler kfis...@gmail.com wrote:
Following up on this -- what's the max number of open file descriptors that
Racket allows? We're seeing some lingering ones (trying to trace the source,
but wondering if this is the problem).
Racket shouldn't have any limit
Our homework submission application, currently running under 5.1.1
with Jay's stateless infrastructure, has been going unresponsive on us
a lot lately. In some cases, the process is still alive but the web
server does not respond to requests. In some cases, the process has
died. While this
Kathi Fisler wrote at 09/06/2011 08:13 PM:
Are there commands we can use when we startup racket or the server
that might give diagnostics to help trace the problem?
Intermittent failures are a headache. In addition to whatever people
advise here, you might want to add your own detailed
On Sep 6, 2011, at 20:13, Kathi Fisler kfis...@gmail.com wrote:
We are not getting core dumps (even when the process dies).
It might be worth checking if any conditions hold under which core dumps are
not written:
http://linux.die.net/man/5/core
Geoff Knauth, Capt, CAP, PA065/CC
6 matches
Mail list logo
