From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.4 required=5.0 tests=PLING_QUERY,RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: archivist@yhbt.net Delivered-To: archivist@dcvr.yhbt.net Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by dcvr.yhbt.net (Postfix) with ESMTP id 8E3BC1F459 for ; Fri, 16 Sep 2011 12:48:08 +0000 (UTC) Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id D8E101858389; Fri, 16 Sep 2011 08:48:07 -0400 (EDT) X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Received: from stomp.cyber.com.au (stomp.cyber.com.au [203.7.155.6]) by rubyforge.org (Postfix) with ESMTP id CBFE6185837C for ; Fri, 16 Sep 2011 08:39:04 -0400 (EDT) Received: from [172.20.10.4] (unknown [58.171.210.144]) by stomp.cyber.com.au (Postfix) with ESMTPSA id 102BB5AE for ; Fri, 16 Sep 2011 22:39:02 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Rainbows! or unicorn? From: russell muetzelfeldt In-Reply-To: <20110916111107.GA15421@dcvr.yhbt.net> Date: Fri, 16 Sep 2011 22:38:59 +1000 Message-Id: References: <20110916111107.GA15421@dcvr.yhbt.net> To: unicorn list X-Mailer: Apple Mail (2.1084) X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org On 16/09/2011, at 9:11 PM, Eric Wong wrote: > :ThreadSpawn + worker_connections=1 and the (default) :Base option are > almost the same in Rainbows! if you don't want to worry about your app > being thread-safe at all. my reason for intending to run worker_connections=1 isn't avoiding threading issues, but to allow app reloads without leaving around old instances of the app in server processes that are handling a 2+ hour upload. I passed on Rainbows::Base just because of the "not intended for production use" comment in the docs. > Rainbows! can (and does by default) limit upload sizes > (client_max_body_size) for handling untrusted clients who may try to > run you out of space. ah, that's a good point. I'll be fronting through Pound for SSL, but having the server process limit upload size would be worthwhile. > Since performance/scalability isn't your concern, it depends on whether > you trust your clients to not upload until you run out of disk space. I trust them to not do that on purpose, but that doesn't mean a lot. :/ cheers Russell ----- Russell Muetzelfeldt Mundus vult decipi, ergo decipiatur. _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying