From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=0.0 required=3.0 tests=AWL,MSGID_FROM_MTA_HEADER, TVD_RCVD_IP shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: "Lin Jen-Shin (godfat)" Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: negative timeout in Rainbows::Fiber::Base Date: Sat, 22 Sep 2012 17:52:11 +0800 Message-ID: References: <20120825024556.GA25977@dcvr.yhbt.net> <20120829211707.GA22726@dcvr.yhbt.net> <20120831013731.GA16613@dcvr.yhbt.net> <20120905232739.GA25153@dcvr.yhbt.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348307571 7356 80.91.229.3 (22 Sep 2012 09:52:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Sep 2012 09:52:51 +0000 (UTC) To: "Rainbows! list" Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Sat Sep 22 11:52:53 2012 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=godfat.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HYC6I4wXuwSkFMnnum5+c0awS5kRNpHpkElDBNfY8Nc=; b=DLUblZ/mVpqYQBm9o3NOgg7vqIkd776Or/jDn3Cjhyn9v+98fkf6PWM1x+ZiSTAK/2 YkCsNVF7LlahbrNE12kOCxeQTpPNlWCSiup+3dfLfDdgKisfhEGV3zRNNvBmcYzhNdnU jCtM8XDrGvDR2A69SLROn5BhjW0CRsNBylIAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=HYC6I4wXuwSkFMnnum5+c0awS5kRNpHpkElDBNfY8Nc=; b=XE7rjWzJ33+XZaX148AU505G8xhLtutUjrzpW6E/R3AJ8kznkq+Awg+rv/5LJ4plWd NrPQ+kBRioYkbqYqd57kAKgupy2bDDYTDaF/6oKCVvWySeYMnl3OUuR1lVCaDK73DJJ8 6NP6qCaT3MGXSfFHcZ6NyNJ9N800QSi8Y4Wul8/EsmMhWigVrUqJr/jzL/q3+/cesjaJ LOwTBJE+cjTUbPvuDu1fav3wYWVRI0tDAbsacGHplTzI2n6AQ99ttmrNEfykVd9G/++o 4n3Id9nRTdZsyMeTwjSZ9CNLYuHwqGTOyC8i7CpMRplILcGC4L/0rz32sfWh7iwcq8SS AnSA== In-Reply-To: <20120905232739.GA25153-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> X-Gm-Message-State: ALoCoQmzhjbl9SLp9Sg9O6SYSnqZfwHbwgS1vb0hDLEozl8dTww8uJDqdNMrl8VFvJcxvJ0eCanM X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:406 Archived-At: Received: from 50-56-192-79.static.cloud-ips.com ([50.56.192.79] helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TFMOK-0001hu-Pc for gclrrg-rainbows-talk@m.gmane.org; Sat, 22 Sep 2012 11:52:53 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 7EACE2E06E; Sat, 22 Sep 2012 09:52:46 +0000 (UTC) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by rubyforge.org (Postfix) with ESMTP id C28732E06D for ; Sat, 22 Sep 2012 09:52:42 +0000 (UTC) Received: by lbao2 with SMTP id o2so170573lba.23 for ; Sat, 22 Sep 2012 02:52:41 -0700 (PDT) Received: by 10.152.46.209 with SMTP id x17mr6285112lam.38.1348307561273; Sat, 22 Sep 2012 02:52:41 -0700 (PDT) Received: by 10.114.19.73 with HTTP; Sat, 22 Sep 2012 02:52:11 -0700 (PDT) On Thu, Sep 6, 2012 at 7:27 AM, Eric Wong wrote: > Simple: we don't read from the socket at all while processing a request > > Extra data the client sends gets buffered in the kernel, eventually TCP > backoff will kick in and the Internet stays usable :> Understood, thanks! I guess this is simple enough that it's a nice trade off, since not every clients would do heavy pipelining. > With the inability to easily stop read callbacks via EM, the socket > buffers constantly get drained so the clients are able to keep sending > data. The only option I've found for Rainbows! + EM was to issue > shutdown(SHUT_RD) if a client attempts to pipeline too much (which > never happens with legitimate clients AFAIK). And the buffer size you set: 0x1c000, I guess that's large enough for most cases. > It shouldn't matter for nginx, I don't think nginx will (ever) pipeline > to a backend. Nowadays nginx can do persistent connections to backends, > though I'm not sure how much of a benefit it is for local sockets. Here's a problem troubles me for a long time, and I failed to figure out what's going on and cannot find a proper fix. I didn't mention this before, because I don't think it's Zbatery/Rainbows' issue, but it turns out that it might be related, and perhaps you would be interested to provide some hints, I would much appreciate it. So we're running all our apps on http://www.heroku.com It's a hosting service that you simply `git push` to deploy your app, worrying not all the complexity regarding deployment. There's a very weird issue running Zbatery/Rainbows on it. I don't remember if Unicorn would be suffering from that since I don't run Unicorn directly for a while now. The problem comes with Rails 3 and its "assets pipeline" feature. It's basically a feature that let your assets (e.g. images, javascripts, css, etc) no longer simple assets which could be served directly via nginx or some other static web server. Like, developers could name their coffeescripts files as: application.coffee.js And when a client is requesting "application.js", that "assets pipeline" thing would compile the coffeescript file into a javascript file on the fly, and return it to the client. We can also "precompile" those assets before deploying to production. Heroku would do this if it detects that the application is deploying is built with Rails 3. If this precompile thing is done successfully, then there's no problems, at least in some of the cases.... But what if precompile failed? In my cases, it would usually cause system stack overflow whenever it tries to compile it on the fly. Oh, suddenly I think maybe it's because I would wrap a fiber around each request in some cases... and it just used too many method calls. I am not sure about that... might check it next time I saw it. Somehow I feel this might be related to persistent connections or pipelined requests, because last time I didn't write the client class correctly to handle pipelined requests as you pointed out, it would also cause some issues regarding "assets pipeline" on Heroku. I believe Heroku is running nginx in front off Zbatery, and if I didn't get pipelined requests correctly, it would result timeout for many of assets the client is asking about. I feel Heroku is using pipelined requests if the client is using this. And the most weird thing I can't understand is, I am trying to convince one of my friend to try out Zbatery, but using ThreadSpawn model would usually cause serving assets timeout, just like in my case where I didn't get pipelined requests correct. Switching to EventMachine solved the problem! Huh? Moreover, once there are some assets timeout issues on EventMachine, too. When I tried to debug this, I put some traces into Rainbows, realizing that sometimes EventMachine didn't call `receive_data' when receiving some pipelined requests. Could it be an eventmachine bug!? Sorry that I wrote so much and it's unclear what's going on, since I don't understand so I can't remember correctly... If you have any idea for a specific case, I can try to provide all the information I could collect. I can't get the nginx configuration Heroku is using though :( > I think your comment is unfortunately representative of a lot of > software development nowadays. > > Embrace pessimism and let it be your guide :) I hope I could understand/realize this sooner :) Cheers, _______________________________________________ Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/rainbows-talk Do not quote signatures (like this one) or top post when replying