On Mon, Sep 20, 2010 at 12:22 PM, Simon Perreault <simon.perrea...@viagenie.ca> wrote: > Does anyone have an answer to that? We just hit this problem in real > life. It's not just theory. > > Thanks, > Simon > > On 2010-09-03 03:49, Yee Keat Phuah wrote: >> Hi, >> >> I am using the http server part of libevent 2.0.6, and currently testing >> it under all sorts of situation. One of the situation I ran into is when >> there are too many connections, there might be "Too Many Open Files" >> returned from the accept() call, that is ok, but the problem is because >> in listener.c:listener_read_cb() function, there's no way I could >> intercept this error message, and maybe stop accepting new connections, >> what happen subsequently is that event_sock_warn just gets called >> thousands of time. >> >> Is there a way that I can intercept this error and act accordingly? >> Probably stop listening for a while? >> >> Thanks in advance. >> >> Cheers, >> Phuah Yee Keat
It looks like we need to add a way for listeners to report errors to the user, rather than warning, and we need to make http respect this error. One challenge is that we've promised not to break existing programs that ignore listener errors, so whatever change we make can't be backwards-incompatible. Here are two possible APIs; I'm not sure which is better. One possibility is that, when a non-retriable error occurs, the callback is invoked with fd set to -1, and errno (LastSocketError) set to the appropriate error. This behavior would break programs that don't expect listeners to ever call the listener callback with a bad fd, so it would have to be off by default, and enabled via an LEV_OPT_* option. Another possibility is to allow code to register a separate error callback for each listener that would get invoked when an error occurred. This seems a little cleaner to me. Thoughts? -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
