From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Kirk Haines" Newsgroups: gmane.comp.lang.ruby.mongrel.devel Subject: Re: Mongrel 2.0 Date: Tue, 18 Nov 2008 07:59:51 -0700 Message-ID: References: <20081118053629.GK1405@zedshaw> Reply-To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227020415 16693 80.91.229.12 (18 Nov 2008 15:00:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2008 15:00:15 +0000 (UTC) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Tue Nov 18 16:01:16 2008 Return-path: Envelope-to: gclrmd-mongrel-development@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7/G0RoXFIid2XpwmNU542jsgMKfd2Th58Wa4etOqQag=; b=JMU5TsY1zNAJcPlA+QA0MDR9NOA0odaZuTdU32OTKUgUQwFc+eLr7uU6/i9lZAjOJa 19pkm4U1qwupmH0fAN0GGmfWTWyBGKEIHer3lIfo4QuvY1ZPS+M1huWuz/bBbnpxPimn EGcvTRDTs4I7a0o2ZHCL3w7XbIjTKq/T1/9NU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Q0fCZePUmszL6mmhEvQ68N+V5Tpx5cPVBpj1V81K0OU49hkh4SQ2L8/Jf37qLBIXUv loSRZ+KDIvJPFLBnHfkf3HK8mhA4HzGS8c3c+v4VU7GeKxA4dtz3L82dkPoaAu+Vy9S3 5ZuzIukzphljqb/FCMm/KEfUn2Ug+XltJvE2A= In-Reply-To: <20081118053629.GK1405@zedshaw> Content-Disposition: inline X-BeenThere: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.mongrel.devel:74 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2S4f-0004rS-6C for gclrmd-mongrel-development@m.gmane.org; Tue, 18 Nov 2008 16:01:05 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 1581018585B1; Tue, 18 Nov 2008 09:59:53 -0500 (EST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by rubyforge.org (Postfix) with ESMTP id A7E8C18585B1 for ; Tue, 18 Nov 2008 09:59:51 -0500 (EST) Received: by yw-out-2324.google.com with SMTP id 9so1270392ywe.59 for ; Tue, 18 Nov 2008 06:59:51 -0800 (PST) Received: by 10.100.5.16 with SMTP id 16mr2141364ane.146.1227020391305; Tue, 18 Nov 2008 06:59:51 -0800 (PST) Received: by 10.100.226.4 with HTTP; Tue, 18 Nov 2008 06:59:51 -0800 (PST) List-Post: On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw 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