It's a Mongrel-configured limit to avoid queuing an impossibly long number of requests in an overloaded situation. So we can return whatever we want.
I think the issue might be, if you can only handle 500 requests p/s, and you are getting 600, if Mongrel closes the connection, at least those 500 will get served, but if Mongrel returns 503, the web server will say "hey, error" and try on the next mongrel, which won't help clear the request queue. The requests will still queue, just at a higher level, and noone will end up getting a request served in a sane amount of time. Evan On Oct 29, 2007 7:55 PM, Will Green <[EMAIL PROTECTED]> wrote: > Evan, I hear you! I know you have the best interests of Mongrel in mind. > > X-SendFile is just a header, right? If so, yeah, it could be moved to core. > > If we're talking the Ruby Sendfile, then I think that should NOT be in core. > I recall many people > having issues (i.e. it doesn't work) with that. > > Regarding the closing of the socket without notice, is that something that > Ruby does, or is it that > a resource limit was reached, and this handle was chosen by the OS to be > closed? If the form, a HTTP > 503 response is appropriate. If the latter, seems to me that another Mongrel > should be employed in a > cluster configuration, or the app code examined to see if it might be the > source of the problem. > > == > Will Green > > > _______________________________________________ > Mongrel-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
