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...
|