Already covered in this thread:
http://rubyforge.org/pipermail/mongrel-users/2007-October/004132.html
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 (
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.txt
)
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.
begin:vcard
fn:Robert Mela
n:Mela;Robert
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
