[Mongrel] random cpu spikes, EBADF errors
evan at cloudbur.st
Mon Oct 29 21:27:52 EDT 2007
I think currently it accepts the connection and then immediately
closes it, which is not consistent with the spec.
On Oct 29, 2007 9:20 PM, Robert Mela <rob at robmela.com> wrote:
> Already covered in this thread:
> Delaying the accept() would be more helpful for load balancers which,
> after a timeout for connect, cycle to another load balancer in the
> pool. Failing that, a 503 would be reasonable, and it offers a hint to
> users as to what's really happening. The open/close does not.
> According to the http/1.1 spec the 503 and refuse-to-accept are both
> correct (
> 10.5.4. 503 Service Unavailable
> The server is currently unable to handle the request due to a
> temporary overloading or maintenance of the server. The implication
> is that this is a temporary condition which will be alleviated after
> some delay. If known, the length of the delay MAY be indicated in a
> Retry-After header. If no Retry-After is given, the client SHOULD
> handle the response as it would for a 500 response.
> Note: The existence of the 503 status code does not imply that a
> server must use it when becoming overloaded. Some servers may
> wish to simply refuse the connection.
> Anyhow, I suggested one means for doing that in a previous thread (
> entitled num_threads or accept/close or sth like that )
> Clifford Heath wrote:
> > Surely it's preferable to just delay the accept() until there's a
> > thread to
> > assign it to? That way the client sees a slow connection-establishment
> > and can draw their own conclusions, including deciding how long to
> > wait or whether to retry.
> > Clifford Heath, Data Constellation.
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users