| Date | Commit message (Collapse) |
|---|
|
Unicorn 5 removes some constants we were using, and constant
lookups + inline caching are waste of time anyways on newer
Rubies with the opt_str_freeze bytecode instruction.
This may reduce performance for folks on older Rubies (probably
not noticeable); but improves performance for folks on newer
Rubies.
|
|
This DRYs up versioning and makes packages easier to distribute.
|
|
This release fixes two EventMachine bugfixes from Lin Jen-Shin
and Mark J. Titorenko. There are also some minor cleanups.
Lin Jen-Shin (1):
event_machine: avoid close on deferred response
Mark J. Titorenko (1):
event_machine: join reactor_thread if it is already running
Eric Wong (2):
event_machine: cleanup confusing assignment
t/GNUmakefile: cleanup test dependencies
|
|
One bugfix allows stream(:keep_open) in Sinatra to work
properly.
Thanks to W. Andrew Loe III for the informative bug report
and reproducible test case.
ref: http://mid.gmane.org/CA+-9oNd1EFqsniPkkPTwu5opTCinbM7-2KHoXov7+y3LE4s4Tg@mail.gmail.com
|
|
Fiber-based concurrency options avoids negative sleep
intervals. Thanks to Lin Jen-Shin for pointing this out.
|
|
For epoll/Cool.io-based concurrency models, shutdown() is now
used to timeout keepalive clients to avoid race conditions.
Minor documentation improvements.
|
|
This release fixes a potential reentrancy deadlock when
using the default logger from the Ruby standard library.
|
|
The deprecated Rainbows::HttpResponse class is finally gone
thanks to Pratik Naik. Logging of errors is more consistent
with the changes in unicorn 4.1.0. There are also minor
documentation updates. See the unicorn 4.1.0 release notes
for more details:
http://bogomips.org/unicorn.git/tag/?id=v4.1.0
|
|
This release includes updates to support WebSockets
under Cramp 0.14 and later. This will be the last
release which supports Cramp 0.13.
There are no changes in this release for non-Cramp
users.
|
|
There are only some minor cleanups in this release and a bump to
kgio 2.5 to remove the dependency on io/wait. kgio 2.5 or later
is now required (kgio 2.6+ will be required in the next
release).
|
|
Rainbows! now scales to more than 1024 worker processes without
special privileges. To enable this, Rainbows! now depends on
Unicorn 4.x and thus raindrops[1].
client_max_header_size directive is added to limit per-client
memory usage in headers.
An experimental StreamResponseEpoll concurrency option now
exists to buffer outgoing responses without any thread-safe
dependencies. Unlike the rest of Rainbows! which works fine
without nginx, this concurrency option is /only/ supported
behind nginx, even more strongly so than Unicorn itself.
non-nginx LAN clients are NOT supported for this. This relies
on the sleepy_penguin[2] RubyGem (and Linux).
There are some minor bug fixes and cleanups all around. See
"git log v3.4.0.." for details.
[1] http://raindrops.bogomips.org/
[2] http://bogomips.org/sleepy_penguin/
|
|
* improved documentation all around, suggestions/comments to further
improve documentation is greatly welcome at: rainbows-talk@rubyforge.org
* added GPLv3 option to the license (now (Ruby|GPLv2|GPLv3), though
Unicorn is still (Ruby|GPLv2) for now)
* added client_header_buffer_size config directive (default 1K)
* small default header buffer size (16K => 1K) to reduce memory usage,
Rails apps with cookie sessions may want to increase this (~2K)
* all concurrency models default to 50 connections per process
* all concurrency models with a secondary :pool_size parameter also
default to 50 (threads/fibers/whatever)
* RLIMIT_NOFILE and RLIMIT_NPROC are automatically increased if needed
* Rainbows::ThreadTimeout middleware rewritten, still not recommended,
lazy people should be using Unicorn anyways :)
* Several experimental Linux-only edge-triggered epoll options:
XEpollThreadSpawn, XEpollThreadPool, XEpoll, and Epoll.
The latter two were in previous releases but never announced.
These require the "sleepy_penguin", "raindrops", and "sendfile" RubyGems
=== Deprecations
* Rainbows::Fiber::IO* APIs all deprecated, Rainbows! will avoid
having any concurrency model-specific APIs in the future and
also avoid introducing new APIs for applications.
* Fiber-based concurrency models are no longer recommended, they're
too fragile for most apps, use at your own risk (they'll continue to
be supported, however). Linux NPTL + Ruby 1.9 is pretty lightweight
and will be even lighter in Ruby 1.9.3 if you're careful with stack
usage in your C extensions.
|
|
We now use IO#trysendfile in the sendfile 1.1.0 to reduce the
cost of generating backtraces for slow clients (from EAGAIN).
Nothing new for people not serving static files (but more
on the way).
Existing "sendfile" gem users must upgrade to 1.1.0
or risk being left without sendfile support at all:
http://bogomips.org/rainbows.git/patch?id=cd8a874d
|
|
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.
|
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
It's the only place we ever use it
|
|
We handle that locally in rainbows/response now
|
|
There is one incompatible change: We no longer assume application
authors are crazy and use strangely-cased headers for "Content-Length",
"Transfer-Encoding", and "Range". This allows us to avoid the
case-insensitivity of Rack::Utils::HeaderHash for a speed boost on the
few apps that already serve thousands of requests/second per-worker.
:Coolio got "async.callback" support like :EventMachine, but it
currently lacks EM::Deferrables which would allow us to call
"succeed"/"fail" callbacks. This means only one-shot response writes
are supported.
There are numerous internal code cleanups and several bugfixes for
handling partial static file responses.
|
|
Cool.io (new version of Rev) support is explicitly added
(it always worked before). ":Coolio" may be used in place
of ":Rev" anywhere in your Rainbows! config file.
There is a new "keepalive_requests" config directive to limit
the number of requests a single connection may make (default:
100, same as nginx). This may be useful for better
load-balancing characteristics.
The old "Rev" prefixes remain supported as long as Cool.io
remains compatible with Rev (likely forever).
Bug fixes:
* Rainbows::ThreadTimeout middleware with multiple clients
* large, pipelined upload errors with Revactor+Coolio(Rev)
* high CPU usage for maintaining idle keepalive on *Fiber*
* needless ThreadPool wakeups
* request env prematurely cleared keepalive requests,
breaking some middlewares such as Clogger.
* "close" not called on body if wrapper and sendfile used together
Various code cleanups, and our RDoc website is JavaScript-free.
See the ChangeLog or git for all changes.
|
|
For HTTP clients living on the edge and pipelining uploads, we
now fully support pipelined requests (as long as the application
consumes each request in its entirety).
|
|
This release is targeted at the minority of web applications
that deal heavily with uploads.
Thanks to Unicorn 3.x, we now support HTTP keepalive for
requests with bodies as long as the application consumes them.
Unicorn 3.x also allows disabling the rewindability requirement
of "rack.input" (in violation of the Rack 1.x spec).
The global client_body_max_size may also be applied per-endpoint
using the Rainbows::MaxBody middleware described in:
http://rainbows.rubyforge.org/Rainbows/MaxBody.html
|
|
This release is merely a milestone in our evolving internal API.
Use of kgio may result in performance improvements under Ruby
1.9.2 with non-blocking I/O-intensive workloads.
The only bugfix is that SIGHUP reloads restores defaults on
unset settings. A similar fix is included in Unicorn 2.0.0
as well.
|
|
Mostly internal changes for kgio (and Unicorn) integration.
There should be no (supported) user-visible changes from
Rainbows! 0.97.0. kgio should improve performance for
concurrency models that use non-blocking I/O internally,
especially under Ruby 1.9.2
|
|
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level. Hopefully
this makes code easier to understand.
|
|
We get basic internal API changes from Unicorn,
code simplifications coming next.
|
|
We now depend on Unicorn 1.1.3 to avoid race conditions during
log cycling. This bug mainly affected folks using Rainbows! as
a multithreaded static file server.
"keepalive_timeout 0" now works as documented for all backends
to completely disable keepalive. This was previously broken
under EventMachine, Rev, and Revactor.
There is a new Rainbows::ThreadTimeout Rack middleware which
gives soft timeouts to apps running on multithreaded backends.
There are several bugfixes for proxying IO objects and the usual
round of small code cleanups and documentation updates.
See the commits in git for all the details.
|
|
For concurrency models that use sendfile or IO.copy_stream, HTTP
Range requests are honored when serving static files. Due to
the lack of known use cases, multipart range responses are not
supported.
When serving static files with sendfile and proxying
pipe/socket bodies, responses bodies are always properly closed
and we have more test cases for dealing with prematurely
disconnecting clients.
Concurrency model specific changes:
EventMachine, NeverBlock -
* keepalive is now supported when proxying pipes/sockets
* pipelining works properly when using EM::FileStreamer
* these remain the only concurrency models _without_
Range support (EM::FileStreamer doesn't support ranges)
Rev, RevThreadSpawn, RevThreadPool -
* keepalive is now supported when proxying pipes/sockets
* pipelining works properly when using sendfile
RevThreadPool -
* no longer supported under 1.8, it pegs the CPU at 100%.
Use RevThreadSpawn (or any other concurrency model) if
you're on 1.8, or better yet, switch to 1.9.
Revactor -
* proxying pipes/sockets with DevFdResponse is much faster
thanks to a new Actor-aware IO wrapper (used transparently
with DevFdResponse)
* sendfile support added, along with Range responses
FiberSpawn, FiberPool, RevFiberSpawn -
* Range responses supported when using sendfile
ThreadPool, ThreadSpawn, WriterThreadPool, WriterThreadSpawn -
* Range responses supported when using sendfile or
IO.copy_stream.
See the full git logs for a list of all changes.
|
|
The FileStreamer class of EventMachine (and by extension
NeverBlock) unfortunately doesn't handle this. It's possible
to do with Revactor (since it uses Rev under the covers),
but we'll support what we can easily for now.
|
|
This will give each concurrency model more control over
particular code paths and serving static files.
|
|
Eric Wong (3):
test_isolate: document why we test with Rack 1.1.0
doc: make RDoc skip private methods
bump Unicorn dependency to 1.1.1
|
|
In addition to the 1.9-only IO.copy_stream, the new sendfile
1.0.0 gem may optionally be used with most concurrency models
(even under 1.8).
See http://rainbows.rubyforge.org/Static_Files.html for more info
Other changes:
* 1.9 encoding bugfix for (Rev)FiberSpawn and FiberPool
* fixed potential rack.input corruption with Revactor
* ThreadPool graceful shutdown no longer blocks until timeout
* optional ServerToken middleware for to display Server: header
* Dependencies bumped to Rack 1.1+ and Unicorn 1.1.0+
* numerous internal cleanups, small bugfixes and speedups
* more concise website oriented at users
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
This release fixes corrupted large response bodies for Ruby 1.8
users with the WriterThreadSpawn and WriterThreadPool models
introduced in 0.93.0. This bug did not affect Ruby 1.9 users
nor the users of any older concurrency models.
There is also a strange new Rainbows::Sendfile middleware. It
is used to negate the effect of Rack::Contrib::Sendfile, if that
makes sense. See the RDoc or
http://rainbows.rubyforge.org/Rainbows/Sendfile.html for all the
gory details.
Finally, the RDoc for our test suite is on the website:
http://rainbows.rubyforge.org/Test_Suite.html
I wrote this document back when the project started but
completely forgot to tell RDoc about it. Personally, this
test suite is one of my favorite parts of the project.
|
|
In our race to have more concurrency options than real sites
using this server, we've added two new and fully supported
concurrency models: WriterThreadSpawn and WriterThreadPool
They're both designed to for serving large static files and work
best with IO.copy_stream (sendfile!) under Ruby 1.9. They may
also be used to dynamically generate long running, streaming
responses after headers are sent (use "proxy_buffering off" with
nginx).
Unlike most concurrency options in Rainbows!, these are designed
to run behind nginx (or haproxy if you don't support POST/PUT
requests) and are vulnerable to slow client denial of service
attacks.
I floated the idea of doing something along these lines back in
the early days of Unicorn, but deemed it too dangerous for some
applications. But nothing is too dangerous for Rainbows! So
here they are now for your experimentation.
|
|
Mostly internal cleanups and small improvements.
The only backwards incompatible change was the addition of the
"client_max_body_size" parameter to limit upload sizes to
prevent DoS. This defaults to one megabyte (same as nginx), so
any apps relying on the limit-less behavior of previous will
have to configure this in the Unicorn/Rainbows! config file:
Rainbows! do
# nil for unlimited, or any number in bytes
client_max_body_size nil
end
The ThreadSpawn and ThreadPool models are now optimized for serving
large static files under Ruby 1.9 using IO.copy_stream[1].
The EventMachine model has always had optimized static file
serving (using EM::Connection#stream_file_data[2]).
The EventMachine model (finally) gets conditionally deferred app
dispatch in a separate thread, as described by Ezra Zygmuntowicz
for Merb, Ebb and Thin[3].
[1] - http://euruko2008.csrug.cz/system/assets/documents/0000/0007/tanaka-IOcopy_stream-euruko2008.pdf
[2] - http://eventmachine.rubyforge.org/EventMachine/Connection.html#M000312
[3] - http://brainspl.at/articles/2008/04/18/deferred-requests-with-merb-ebb-and-thin
|
|
Since Rainbows! is supported when exposed directly to the
Internet, administrators may want to limit the amount of data a
user may upload in a single request body to prevent a
denial-of-service via disk space exhaustion.
This amount may be specified in bytes, the default limit being
1024*1024 bytes (1 megabyte). To override this default, a user
may specify `client_max_body_size' in the Rainbows! block
of their server config file:
Rainbows! do
client_max_body_size 10 * 1024 * 1024
end
Clients that exceed the limit will get a "413 Request Entity Too
Large" response if the request body is too large and the
connection will close.
For chunked requests, we have no choice but to interrupt during
the client upload since we have no prior knowledge of the
request body size.
|
|
* maint:
Rainbows! 0.91.1 - use a less-broken parser from Unicorn
|
|
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.
|
|
Every concurrency model does this the same way.
This removes the Rainbows::Const::LOCALHOST constant and
may break some existing apps that rely on it.
|
|
Unicorn 0.97.0 has a bunch of internal cleanups and small fixes
and this is mainly to resync with those changes.
keepalive_timeout now defaults to 5 seconds (from 2 seconds
previous). This should help out clients on slower connections.
Some small fixes and cleanups:
* Rainbows::Fiber::IO objects may leak if a rare app uses them
explicitly with FiberSpawn/FiberPool-only (not RevFiberSpawn)
* quiet down ENOTCONN handling, there's nothing we can do about
this error so we won't fill our logs with it.
|
|
This release contains minor bugfixes/compatibility improvements
for ThreadSpawn, ThreadPool and EventMachine users.
Excessive error messages from spurious wakeups using
ThreadSpawn/ThreadPool under most platforms are silenced. Only
Ruby 1.9 users under Linux were unaffected by this bug.
EventMachine users may now use EM::Deferrable objects in
responses, vastly improving compatibility with existing
async_sinatra apps.
|
|
This release should fix ThreadSpawn green thread blocking issues
under MRI 1.8. Excessive socket closing is avoided when using
Thread* models with Sunshowers (or clients disconnecting
during uploads).
There is a new RevFiberSpawn concurrency model which combines
Rev with the traditional FiberSpawn model.
|
|
No point in becoming the straw that causes a rehash
since hardly anybody uses it.
|
|
Make RACK_DEFAULTS == Unicorn::HttpRequest::DEFAULTS
and LOCALHOST == Unicorn::HttpRequest::LOCALHOST
No point in having a duplicate objects, and it also makes it
easier to share runtime constant modifications between servers.
|
|
This release introduces compatibility with Sunshowers, a library
for Web Sockets, see http://rainbows.rubyforge.org/sunshowers
for more information. Several small cleanups and fixes.
Eric Wong (20):
add RevThreadPool to README
rev: do not initialize a Rev::Loop in master process
rainbows.1: update headers
do not log IOError raised during app processing
move "async.callback" constant to EvCore
larger thread pool default sizes ({Rev,}ThreadPool)
ev_core: no need to explicitly close TmpIOs
EventMachine: allow usage as a base class
NeverBlock: resync with recent our EM-related expansion
RevThread*: move warning message to a saner place
EventMachineDefer: preliminary (and) broken version
TODO: add EM Deferrables
RevThread*: remove needless nil assignment
README: HTML5 Web Sockets may not be supported, yet...
env["hack.io"] for Fiber*, Revactor, Thread* models
EventMachineDefer is experimental
README: add Sunshowers reference
Rakefile: resync with Unicorn
doc/comparison: add Web Sockets to comparison
README updates
|
|
This exposes a client IO object directly to the underlying
application.
|
|
This release fixes a memory leak in our existing Revactor
concurrency model. A new RevThreadPool concurrency model has
been added as well as small cleaups to exit handling in workers.
|
|
keepalive_timeout (default: 2 seconds) is now supported to
disconnect idle connections. Several new concurrency models
added include: NeverBlock, FiberSpawn and FiberPool; all of
which have only been lightly tested. RevThreadSpawn loses
streaming input support to become simpler and faster for the
general cases. AppPool middleware is now compatible with all
Fiber-based models including Revactor and NeverBlock.
A new document gives a summary of all the options we give you:
http://rainbows.rubyforge.org/Summary.html
If you're using any of the Rev-based concurrency models, the
latest iobuffer (0.1.3) gem will improve performance. Also,
RevThreadSpawn should become usable under MRI 1.8 with the next
release of Rev (0.3.2).
|
|
Client shutdowns/errors when streaming "rack.input" into the
Rack application are quieter now. Rev and EventMachine workers
now shutdown correctly when the master dies. Worker processes
now fail gracefully if log reopening fails. ThreadSpawn and
ThreadPool models now load Unicorn classes in a thread-safe way.
There's also an experimental RevThreadSpawn concurrency
model which may be heavily reworked in the future...
Eric Wong (30):
Threaded models have trouble with late loading under 1.9
cleanup worker heartbeat and master deathwatch
tests: allow use of alternative sha1 implementations
rev/event_machine: simplify keepalive checking a bit
tests: sha1.ru now handles empty bodies
rev: split out further into separate files for reuse
rev: DeferredResponse is independent of parser state
remove unnecessary class variable
ev_core: cleanup handling of APP constant
rev: DeferredResponse: always attach to main loop
initial cut of the RevThreadSpawn model
rev_thread_spawn/revactor: fix TeeInput for short reads
rev_thread_spawn: make 1.9 TeeInput performance tolerable
tests: add executable permissions to t0102
tests: extra check to avoid race in reopen logs test
rev_thread_spawn: 16K chunked reads work better
tests: ensure proper accounting of worker_connections
tests: heartbeat-timeout: simplify and avoid possible race
tests: ensure we process "START" from FIFO when starting
http_response: don't "rescue nil" for body.close
cleanup error handling pieces
tests: more stringent tests for error handling
revactor/tee_input: unnecessary error handling
gracefully exit workers if reopening logs fails
revactor/tee_input: raise ClientDisconnect on EOFError
bump versions since we depend on Unicorn::ClientShutdown
revactor/tee_input: share error handling with superclass
RevThreadSpawn is still experimental
Revert "Threaded models have trouble with late loading under 1.9"
Rakefile: add raa_update task
|
|
|