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: X-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, T_RP_MATCHES_RCVD,URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: yahns-public@yhbt.net Received: from localhost (dcvr.yhbt.net [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPSA id EA0C71FAE7; Thu, 11 Jun 2015 19:58:02 +0000 (UTC) Date: Thu, 11 Jun 2015 19:58:02 +0000 From: Eric Wong To: ruby-talk@ruby-lang.org, yahns-public@yhbt.net Subject: [ANN] yahns 1.8.0 -_- sleepy app server for Ruby Message-ID: <20150611-yahns-1.8.0-minor-updates-release@yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: A Free Software, multi-threaded, non-blocking network application server designed for low _idle_ power consumption. It is primarily optimized for applications with occasional users which see little or no traffic. yahns currently hosts Rack/HTTP applications, but may eventually support other application types. Unlike some existing servers, yahns is extremely sensitive to fatal bugs in the applications it hosts. minor updates Most notably, the Rack response body is now closed during rack.hijack. Middlewares such as Rack::Lock (used by Rails) break badly unless the response body is closed on hijack, so we will close it to follow the lead of other popular Rack servers. While it's unclear if there's anybody using rack.hijack besides yahns/proxy_pass we'll try to emulate the behavior of other servers as much as possible. ref: https://github.com/ngauthier/tubesock/issues/10 We'll also support SIGWINCH if not daemonized This has no effect for the (default) single process case with no master/worker relationship as that does not support SIGWINCH. Some process managers such as foreman and daemontools rely on yahnsnot daemonizing, but we still want to be able to process SIGWINCH in that case. stdout and stderr may be redirected to a pipe (for cronolog or similar process), so those are less likely to be attached to a TTY than stdin. This also allows users to process SIGWINCH when running inside a regular terminal if they redirect stdin to /dev/null. This follows unicorn commit a6077391bb62d0b13016084b0eea36b987afe8f0 Thanks to Dan Moore for suggesting it on the unicorn list. A few more minor changes, more memory reduction changes coming... * proxy_pass: no point in closing StringIO * proxy_pass: allow filtering or overriding response headers * support SIGWINCH even if not daemonized * use Unicorn::HttpParser#response_start_sent accessor * reduce inline constant cache overheads * proxy_pass: skip tests if kcar is missing * ensure body is closed during hijack Please note the disclaimer: yahns is extremely sensitive to fatal bugs in the apps it hosts. There is no (and never will be) any built-in "watchdog"-type feature to kill stuck processes/threads. Each yahns process may be handling thousands of clients; unexpectedly killing the process will abort _all_ of those connections. Lives may be lost! yahns hackers are not responsible for your application/library bugs. Use an application server which is tolerant of buggy applications if you cannot be bothered to fix all your fatal bugs. * git clone git://yhbt.net/yahns * http://yahns.yhbt.net/README * http://yahns.yhbt.net/NEWS.atom.xml * we like plain-text email yahns-public@yhbt.net * and archive all the mail we receive: http://yhbt.net/yahns-public/ -- EW