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=1.7 required=3.0 tests=AWL,HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER,RDNS_NONE shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: Timeout on Rainbows! Date: Fri, 23 Aug 2013 19:35:19 +0000 Message-ID: <20130823193519.GA30201@dcvr.yhbt.net> References: 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 1377286523 22226 80.91.229.3 (23 Aug 2013 19:35:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Aug 2013 19:35:23 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Fri Aug 23 21:35:26 2013 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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 X-Broken-Reverse-DNS: no host name found for IP address 50.56.192.79 Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:518 Archived-At: Received: from [50.56.192.79] (helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VCx8m-00086C-IZ for gclrrg-rainbows-talk@m.gmane.org; Fri, 23 Aug 2013 21:35:24 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id A48412E19A; Fri, 23 Aug 2013 19:35:24 +0000 (UTC) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 585082E145 for ; Fri, 23 Aug 2013 19:35:22 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 33BC01F464; Fri, 23 Aug 2013 19:35:20 +0000 (UTC) "Lin Jen-Shin (godfat)" wrote: > I am reworking on thread pool for EventMachine, and just realized that > Rainbows doesn't try to put a timeout for each request. Previously, > I thought the timeout setup in Unicorn would be used for each request. The normal timeout is only a last resort (it works when the VM is hosed on a worker). ThreadTimeout isn't nearly as reliable because it works on the same VM/process, and it's still always preferable to rely on "local" timeouts exposed by every library. (see http://unicorn.bogomips.org/Application_Timeouts) > Then I found Rainbows::ThreadTimeout is probably what I want. > I wonder, does that make sense to do something like this, wrap the > application with Rainbows::ThreadTimeout with the same timeout > time in Unicorn automatically? > Because I saw this in EventMachine model: > > def worker_loop(worker) # :nodoc: > init_worker_process(worker) > server = Rainbows.server > server.app.respond_to?(:deferred?) and > server.app = TryDefer.new(server.app) > [...] That's only because other servers (Thin) support this non-standard extension by default. Otherwise, I've always been strongly against adding non-standard extensions/features into the Rack middleware stack. > and I think in most cases we would want this timeout for each > request. The down side might be that then the users cannot > use their own Rainbows::ThreadTimeout (maybe?) or setup a custom > threshold. Right. And some users (e.g. myself) don't ever use either timeout feature. We audit every single line of code and make sure all potentially long-running method calls have timeouts set appropriately. (IMNSHO, this is the _only_ way to write applications for a multi-threaded/evented platform) > Probably then we could introduce another timeout/threshold config > in Configurator? I feel it would be common enough. Not worth it. It's not reliable enough nor generally useful enough compared to the regular timeout (which again, is a last resort). _______________________________________________ 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