mirror of mongrel-development@rubyforge.org (inactive)
 help / color / mirror / Atom feed
From: "Kirk Haines" <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Subject: Re: Mongrel 2.0
Date: Tue, 18 Nov 2008 07:59:51 -0700	[thread overview]
Message-ID: <f4cd26df0811180659n218275a4hf06313ca8f48eed0@mail.gmail.com> (raw)
In-Reply-To: <20081118053629.GK1405@zedshaw>

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

  parent reply	other threads:[~2008-11-18 15:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-17 20:32 Evan Weaver
     [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-17 20:33   ` Evan Weaver
     [not found]     ` <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-17 20:47       ` Ezra Zygmuntowicz
     [not found]         ` <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-11-17 22:55           ` Filipe Lautert
2008-11-18  5:36   ` Zed A. Shaw
2008-11-18  5:49     ` Evan Weaver
     [not found]       ` <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20  2:31         ` Wayne Seguin
2008-11-18 14:59     ` Kirk Haines [this message]
     [not found]       ` <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-18 16:22         ` Evan Weaver
2008-11-20  3:09   ` Luis Lavena
     [not found]     ` <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20  4:39       ` Kirk Haines
     [not found]         ` <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20  5:54           ` Tony Arcieri
     [not found]             ` <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-21 18:03               ` Evan Weaver
2008-12-06  0:48   ` Eric Wong
replies disabled, historical list

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).