[Mongrel] random cpu spikes, EBADF errors

Robert Mela rob at robmela.com
Mon Oct 29 21:20:12 EDT 2007

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071029/0d1dce2c/attachment.vcf 

More information about the Mongrel-users mailing list