Re: Mongrel 2.0

["Kirk Haines" <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> 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