Files | Admin

Notes:

Release Name: 4.1.2

Notes:
Zbatery 4.1.2 - we don't fork, but our apps may!

Zbatery is an HTTP server for Rack applications on systems that either
do not support fork(), or have no memory (nor need) to run the
master/worker model.  It is based on Rainbows! (which is based on
Unicorn (which is based on Mongrel)) and inherits parts of each.
Zbatery supports your choice of all the thread/fiber/event/actor-based
concurrency models and Rack middleware that Rainbows! supports (or will
ever support) in a single process.

* http://zbatery.bogomip.org/
* rainbows-talk@rubyforge.org
* git://bogomips.org/zbatery.git
* http://zbatery.bogomip.org/NEWS.atom.xml

Changes:

There are two bugfixes in this release.  Rack applications that
use fork() internally should now behave as-expected when
receiving SIGCHLD.  The pid file is also unlinked during a
graceful shutdown.



Changes: GIT-VERSION-GEN | 2 +- lib/zbatery.rb | 6 ++++-- t/sigchld.ru | 22 ++++++++++++++++++++++ t/t0003-reopen-logs.sh | 17 +++++++++++++++-- t/t0006-sigchld.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 86 insertions(+), 5 deletions(-) commit 5c36afdcab8af15cf979e76e87b6c99f857480bc Author: Eric Wong Date: Mon Dec 5 18:36:12 2011 +0000 Zbatery 4.1.2 - we don't fork, but our apps may! There are two bugfixes in this release. Rack applications that use fork() internally should now behave as-expected when receiving SIGCHLD. The pid file is also unlinked during a graceful shutdown. commit 36936f0d729d06c5d2dda2147b9404055c1d0dd9 Author: Eric Wong Date: Fri Dec 2 17:38:48 2011 -0800 use default SIGCHLD handler Applications that fork() will trigger SIGCHLD. As unicorn is based on the master+worker model, its master process handles SIGCHLD when workers die. However, Zbatery is single-process and has no workers, it does not need a custom SIGCHLD handler. commit 90d1d769b9af83d6d1464658169e72b9467ab384 Author: Eric Wong Date: Wed Nov 23 09:52:48 2011 +0000 zbatery: unlink pid file during graceful shutdown We don't have the same shutdown sequence as unicorn, there is no need to leave pid files hanging around during upgrades. Of course we can't guarantee this (or any) behavior for non-graceful shutdowns...