about summary refs log tree commit homepage
path: root/lib/zbatery.rb
DateCommit message (Collapse)
2014-05-14zbatery 4.2.0 v4.2.0
Lots of updates for deprecated broken stuff, and we have a good version number to go with it ;) See the corresponding Rainbows! release for more details: http://bogomips.org/rainbows-public/m/20140512074058.GB29516@dcvr.yhbt.net One notable new feature is the addition of the --no-default-middleware option which I forgot about and should've released last year when Rainbows! got it :x Eric Wong (6): Rakefile: s/freshmeat.net/freecode.com/ Rakefile: kill raa_update task rubyforge death updates update license to GPLv2+ warn about premature grandparent death on daemonization update for Rainbows! compatibility Lin Jen-Shin (1): Add -N or --no-default-middleware option.
2014-05-14update for Rainbows! compatibility
Recent versions of Rainbows! and unicorn broke compatibility during shutdown.
2014-05-14warn about premature grandparent death on daemonization
This may cause failures if some process nukes the grandparent too soon.
2011-12-05Zbatery 4.1.2 - we don't fork, but our apps may! v4.1.2
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.
2011-12-02use 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.
2011-11-23zbatery: 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...
2011-09-02Zbatery 4.1.1 - small bugfix v4.1.1
This release fixes a potential reentrancy deadlock when using the default logger from the Ruby standard library.
2011-08-31avoid potential Logger deadlocks in signal handling
If any combination of signals are sent to Zbatery in a short period of time, the Mutex used by the default Logger implementation may deadlock since Mutex synchronization is not reentrant-safe. By spawning a thread, we can take advantage of the thread-safety and avoid the reentrancy-safety issue of acquiring a mutex inside a signal handler. Users of alternative logger implementations (or monkey-patched ones) are possibly not affected. Users of the logger_mp_safe.rb monkey-patch distributed[1] with unicorn are not affected. [1] http://unicorn.bogomips.org/examples/logger_mp_safe.rb
2011-08-20Zbatery 4.1.0 - pull in latest changes from unicorn 4.1.0 v4.1.0
Logging of errors is more consistent in this release. See the unicorn 4.1.0 release notes for more details: http://bogomips.org/unicorn.git/tag/?id=v4.1.0
2011-06-27Zbatery 4.0.0 - another Rainbows! resync v4.0.0
This gets most of the improvements Rainbows! 4.0.0 got: * client_max_header_size directive is added to limit per-client memory usage in headers. * An experimental StreamResponseEpoll concurrency option * minor bugfixes, minor stack depth reduction Since Zbatery doesn't fork workers, the ability of Unicorn 4.x to scale to a large amount of worker processes doesn't matter to us.
2011-06-27remove DeadIO class
It's no longer needed.
2011-06-27remove Zbatery.run method
It's unnecessary making the stack deeper. Stop it.
2011-06-27resync with Rainbows! 4.0.0
There are some internal changes in Unicorn and Rainbows! 4.x
2011-05-21Zbatery 3.4.0 - another Rainbows! resync v3.4.0
This release fixes dependencies on Rainbows! and gets all the improvements Rainbows! 3.4.0 got: * Kgio.autopush support for multi-threaded configurations * Immediate disconnect of idle clients on SIGQUIT for concurrency models where idle clients are cheap to maintain.
2011-05-16Zbatery 3.3.0 - another Rainbows! resync v3.3.0
Like Rainbows! 3.3.0, we've added the GPLv3 to our license (in addition to GPLv2 and Ruby terms). See Rainbows! 3.3.0 release notes and news for more infor on changes: http://rainbows.rubyforge.org/NEWS.html
2011-02-11Zbatery 3.1.0 - we stole release notes from Rainbows! v3.1.0
Small bug fixes that have been sitting around, not much but it's already been one month since our last release. * Unicorn dependency updated to 3.4.0, so we get IPv6 support and Kgio.autopush support for ":tcp_nopush => true" users. * Optional :pool_size argument is fixed for NeverBlock and CoolioThreadPool users. * Mostly minor internal code cleanups * Sunshowers support removed, it was out-of-date and unmaintained. Cramp remains supported for now. * X-Rainbows-* response headers support removed, nobody used it. There are severalnew features in this release not documented here. Consider any new features not mentioned in these release notes to be subject to removal/renaming in future releases.
2011-02-11update for internal API change in rainbows.git
About to become Rainbows 3.1.0 soon
2011-01-11Zbatery 3.0.0 - Rainbows! 3.0.0 resync v3.0.0
The ugly "Rainbows::G" constant is no longer.
2010-12-29Zbatery 0.6.0 - Rainbows! 2.1.x resync v0.6.0
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-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-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-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-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-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.
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-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-10prep for release v0.0.0
2009-12-09trap and noop SIGWINCH, too
2009-11-27initial