On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <[EMAIL PROTECTED]> wrote: > Very cool, nice work. One small comment... > > On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >> Hi Mongrels, >> >> - Error code instead of connection-close, as discussed earlier > > With this do you mean returning one of the many error codes in an HTTP > response when the server is overloaded? > > I would recommend against that if that's the case. In theory it's nice > to return an error code to clients that could be waiting. In practice, > your queue is already overloaded, so taking more time to send a response > to clients only adds to the problem. In a modern system this isn't such > a big deal, but in Ruby it becomes a mess because of the file id limits > in the select loop.
In an overload situation, I think that just dropping the connection is an acceptable thing to do, though. The mongrel is overloaded, so it is a correct and beneficial response on the part of the proxy to assume something is wrong with it, and to stop sending traffic to it for a while. The use case for sending a response instead of just dropping the connection is when the HTTP parser throws an exception because of malformed HTTP. Currently that results in an immediate closed connection. The problem there is that upstream proxies can assume that getting the connection cut unexpectedly means that the mongrel itself has a problem. If that proxy responds to this by removing that mongrel from the proxy rotation for a period of time, one misbehaving client, whether intentionally or unintentionally, can DOS a whole cluster. The fix is to just return a canned 400 response before closing. Kirk Haines _______________________________________________ Mongrel-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-development
