about summary refs log tree commit homepage
DateCommit message (Collapse)
2010-12-29Zbatery 0.6.0 - Rainbows! 2.1.x resync v0.6.0
2010-12-29packaging updates (wrongdoc!)
2010-12-29resync with Rainbows! 2.1.0
2010-11-20Zbatery 0.5.0 - Rainbows! 2.0.x sync v0.5.0
This release syncs up with the latest from Rainbows! 2.0.x and Unicorn 3.0.x. See Rainbows! and Unicorn release notes and changelogs for relevant details.
2010-10-28Zbatery 0.4.0 - Rainbows! 1.0.x sync v0.4.0
This release syncs up with the latest from Rainbows! 1.0.x and Unicorn 2.0.x
2010-10-28updates for Rainbows! 1.0.0
There are some internal API changes here.
2010-08-28bump dependencies on Unicorn + Rainbows!
Small fixes from both that are worth having to ease support.
2010-07-11Zbatery v0.3.1 - quiet EOF errors from clients v0.3.1
Eric Wong (3): update local.mk.sample for 0.3.0 Fix documentation generation bump Rainbows! (and Unicorn) dependencies
2010-07-11bump Rainbows! (and Unicorn) dependencies
Unicorn 1.1.0 had constant resolution problems with TeeInput
2010-07-10Fix documentation generation
.document needed to be updated for RDoc 2.5.x
2010-07-10update local.mk.sample for 0.3.0
2010-07-10Zbatery v0.3.0 - for newer Rainbows! v0.3.0
Rainbows! v0.95.0 is more awesome than v0.94.0, so we've updated ourselves to use it and be more awesome as well!
2010-07-10gemspec: small doc updates
2010-07-10add additional tests for newish Rainbows! features
2010-07-10updates for Rainbows! 0.95.0
Rainbows! 0.95.0 made some incompatible changes, so update everything. Unfortunately we have to avoid subclassing here. Tests use isolate now.
2010-04-19Zbatery 0.2.1 - use a less-broken parser from Unicorn v0.2.1
This release fixes a denial-of-service vector for deployments exposed directly to untrusted clients. The HTTP parser in Unicorn <= 0.97.0 would trip an assertion (killing the associated worker process) on invalid Content-Length headers instead of raising an exception. Since Rainbows! and Zbatery supports multiple clients per worker process, all clients connected to the worker process that hit the assertion would be aborted. Deployments behind nginx are _not_ affected by this bug, as nginx will reject clients that send invalid Content-Length headers. The status of deployments behind other HTTP-aware proxies is unknown. Deployments behind a non-HTTP-aware proxy (or no proxy at all) are certainly affected by this DoS. Users are strongly encouraged to upgrade as soon as possible, there are no other changes besides this bug fix from Rainbows! 0.91.0 nor Unicorn 0.97.0 This bug affects all previously released versions of Rainbows! and Zbatery.
2010-03-01t0003: fix error log check
We don't have "worker" processes in here.
2010-03-01Zbatery 0.2.0 - Unicorn/Rainbows! resync v0.2.0
Eric Wong (7): use Unicorn.builder to parse config.ru switches import selected parts of test suite from Rainbows! gemspec: depend on newer Unicorn for Unicorn.builder support "user" directive outside of after_fork hook MRI 1.8 thread fix to avoid blocking accept() disable more Unicorn methods support Unicorn 0.96.0+ ready_pipe daemonization
2010-03-01support Unicorn 0.96.0+ ready_pipe daemonization
ready_pipe allows the controlling process to detect errors more reliably.
2010-03-01disable more Unicorn methods
init_self_pipe! and trap_deferred are worthless and possibly harmful to us
2010-03-01MRI 1.8 thread fix to avoid blocking accept()
Rainbows! commit ee7fe220ccbc991e1e7cbe982caf48e3303274c7 Under MRI 1.8, listen sockets do not appear to have the nonblocking I/O flag on by default, nor does it set the nonblocking I/O flag when calling #accept (but it does when using #accept_nonblock, of course). Normally this is not a problem even when using green threads since MRI will internally select(2) on the file descriptor before attempting a blocking (and immediately successful) accept(2). However, when sharing a listen descriptor across multiple processes, spurious wakeups are likely to occur, causing multiple processes may be woken up when a single client connects. This causes a problem because accept(2)-ing on multiple threads/processes for a single connection causes blocking accepts in multiple processes, leading to stalled green threads. This is not an issue under 1.9 where a blocking accept() call unlocks the GVL to let other threads run.
2010-03-01support "user" directive outside of after_fork hook
This is new in Unicorn 0.97.0, and makes sense to us since we don't fork. It won't work as nicely with log reopening in some cases, but it's better than nothing
2010-03-01gemspec: depend on newer Unicorn for Unicorn.builder
2010-03-01import selected parts of test suite from Rainbows!
2010-02-28use Unicorn.builder to parse config.ru switches
Less code to maintain this way.
2010-02-13Zbatery 0.1.1 v0.1.1
Unicorn had a memory that didn't affect Unicorn, but only Rainbows!, so we bumped the dependency on Rainbows! which in turn bumped the dependency on Unicorn... Also some minor documentation updates.
2010-02-13gemspec: bump Rainbows! dependency (leak fix)
Rainbows! >= 0.90.2 depends on Unicorn >= 0.96.1, which will work around a memory leak found in previous versions of Unicorn::HttpParser.
2009-12-24doc: update manpage since Unicorn got new features
working_directory and Worker#user got added over time, so recommending Dir.chdir and Process::UID.change_privilege is bad.
2009-12-22Zbatery 0.1.0 v0.1.0
This gem release allows compatibility with newer versions of Rainbows! This also fixes a bug when $stdout is not redirected to a file.
2009-12-22ficks speling eror in README
2009-12-21GNUmakefile: releases push tgz to Rubyforge
2009-12-16avoid breaking user switching with a single process
$stdout may not have been a chown-able file descriptor, so throw in a dummy object there that absorbs chown calls.
2009-12-15doc: update README, add FAQ
* make it clear we depend on Unicorn and Rainbows! * point out Sunshowers * add FAQ
2009-12-14gemspec: relax Rainbows! dependency
We do not expect Rainbows! internals we depend on to change significantly before Rainbows! 1.0.0.
2009-12-10prep for release v0.0.0
2009-12-09trap and noop SIGWINCH, too
2009-11-29do not expand paths given by shell
Shells already expand '~' before the executables see it, and relative paths inside symlinks can get set incorrectly to the actual directory name, and not the (usually desired) symlink name for things like Capistrano. Since our paths are now unexpanded, we must now check the "working_directory" directive and raise an error if the user specifies the config file in a way that makes the config file unreloadable.
2009-11-27initial