Date | Commit message (Collapse) |
|
This release fixes a potential reentrancy deadlock when
using the default logger from the Ruby standard library.
|
|
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
|
|
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
|
|
|
|
|
|
...via Rainbows! 4.3.0.
|
|
We have no public API
|
|
We want email (but not the HTML kind :P)
|
|
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.
|
|
It's no longer needed.
|
|
It's unnecessary making the stack deeper. Stop it.
|
|
There are some internal changes in Unicorn and Rainbows! 4.x
|
|
This fixes locale issues with grep and adds check-warnings.
|
|
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.
|
|
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
|
|
GPLv2 and Ruby-specific terms remain intact, but this means
we can be combined and redistributed with GPLv3-only software
(once Unicorn has GPLv3 added to its license).
|
|
copy-and-paste error from Rainbows!
|
|
Ruby 1.9.3dev switched to BSD but we remain under the same terms
as the old Ruby 1.8 license. Mongrel2 exists now and also uses
the BSD, so don't confuse people with that, either.
|
|
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.
|
|
Minor updates, really.
|
|
bogomips.org went on a URL diet!
|
|
|
|
About to become Rainbows 3.1.0 soon
|
|
The ugly "Rainbows::G" constant is no longer.
|
|
|
|
|
|
|
|
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.
|
|
This release syncs up with the latest from Rainbows! 1.0.x
and Unicorn 2.0.x
|
|
There are some internal API changes here.
|
|
Small fixes from both that are worth having to ease support.
|
|
Eric Wong (3):
update local.mk.sample for 0.3.0
Fix documentation generation
bump Rainbows! (and Unicorn) dependencies
|
|
Unicorn 1.1.0 had constant resolution problems
with TeeInput
|
|
.document needed to be updated for RDoc 2.5.x
|
|
|
|
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!
|
|
|
|
|
|
Rainbows! 0.95.0 made some incompatible changes, so update
everything. Unfortunately we have to avoid subclassing here.
Tests use isolate now.
|
|
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.
|
|
We don't have "worker" processes in here.
|
|
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
|
|
ready_pipe allows the controlling process to detect
errors more reliably.
|
|
init_self_pipe! and trap_deferred are worthless and
possibly harmful to us
|
|
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.
|
|
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
|
|
|
|
|
|
Less code to maintain this way.
|
|
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.
|