about summary refs log tree commit homepage
path: root/lib/rainbows/const.rb
DateCommit message (Collapse)
2011-03-15Rainbows! 3.2.0 - trying to send files to slow clients v3.2.0
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
2011-02-11Rainbows! 3.1.0 - minor updates 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-01-20remove support for Sunshowers
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.
2011-01-20ev_core: localize 413 error constant
It's the only place we ever use it
2011-01-20remove unused 416 error constants/exceptions
We handle that locally in rainbows/response now
2011-01-11Rainbows! 3.0.0 - serving the fastest apps to slow clients faster! v3.0.0
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.
2010-12-29Rainbows! 2.1.0 - Cool.io, bugfixes and more!
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.
2010-12-03Rainbows! 2.0.1 - upload pipelining fixes v2.0.1
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).
2010-11-20Rainbows! 2.0.0 - minority rules! v2.0.0
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
2010-10-28Rainbows! 1.0.0 - internal cleanups v1.0.0
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.
2010-10-26Rainbows! 1.0.0pre1 - kinder, gentler I/O v1.0.0pre1
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
2010-10-22unindent most files
This simplifies and disambiguates most constant resolution issues as well as lowering our identation level. Hopefully this makes code easier to understand.
2010-10-21unicorn 2.x updates + kgio
We get basic internal API changes from Unicorn, code simplifications coming next.
2010-08-28Rainbows! 0.97.0 v0.97.0
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.
2010-08-03Rainbows! 0.96.0 - range support v0.96.0
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.
2010-07-22enable Range: responses for static files for most models
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.
2010-07-19refactor response handling for each concurrency model
This will give each concurrency model more control over particular code paths and serving static files.
2010-07-11Rainbows! v0.95.1 - depend on newer Unicorn v0.95.1
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
2010-07-10Rainbows! 0.95.0 - sendfile() support! v0.95.0
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
2010-07-10doc: avoid documenting internals on RDoc website
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.
2010-06-04Rainbows! 0.94.0 - one eight ate my homework! v0.94.0
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.
2010-05-29Rainbows! 0.93.0 - MOAR!!!1 v0.93.0
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.
2010-05-04Rainbows! 0.92.0 - inching towards the pot of gold v0.92.0
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
2010-05-03add client_max_body_size config directive
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.
2010-04-19Merge branch 'maint'
* maint: Rainbows! 0.91.1 - use a less-broken parser from Unicorn
2010-04-19Rainbows! 0.91.1 - use a less-broken parser from Unicorn v0.91.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-28cleanup: avoid redundant REMOTE_ADDR logic
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.
2010-03-01Rainbows! 0.91.0 - Unicorn resync v0.91.0
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.
2009-12-30Rainbows! 0.90.1 v0.90.1
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.
2009-12-22Rainbows! 0.90.0 v0.90.0
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.
2009-12-22avoid setting "rainbows.autochunk" by default
No point in becoming the straw that causes a rehash since hardly anybody uses it.
2009-12-13share some constants with Unicorn
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.
2009-12-13Rainbows! 0.9.0 v0.9.0
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
2009-12-11env["hack.io"] for Fiber*, Revactor, Thread* models
This exposes a client IO object directly to the underlying application.
2009-12-02Rainbows! 0.8.0 v0.8.0
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.
2009-11-29Rainbows! 0.7.0 v0.7.0
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).
2009-11-15Rainbows! 0.6.0 - bugfixes galore v0.6.0
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
2009-11-13bump versions since we depend on Unicorn::ClientShutdown
2009-11-05Rainbows! 0.5.0 v0.5.0
We depend on the just-released Unicorn 0.94.0 for the fixed trailer handling. As with `unicorn', the `rainbows' executable now sets and respects ENV["RACK_ENV"]. Also small fixes and cleanups including better FreeBSD 7.2 compatibility and less likely to over-aggressively kill slow/idle workers when a very low timeout is set. Eric Wong (20): rev: split out heartbeat class bump Unicorn dependency to (consistently) pass tests tests: avoid single backquote in echo event_machine: avoid slurping when proxying tests: make timeout tests reliable under 1.9 thread_pool: comment for potential SMP issue under 1.9 Allow 'use "model"' as a string as well as symbol Rev model is the only user of deferred_bodies ev_core: use Tempfile instead of Unicorn::Util::tmpio ev_core: ensure quit is triggered on all errors rainbows: set and use process-wide ENV["RACK_ENV"] http_server: add one second to any requested timeout thread_pool: update fchmod heartbeat every second t0004: tighten up timeout test ev_core: remove Tempfile usage once again cleanup: remove unused t????.ru test files tests: staggered trailer upload test ensure RACK_ENV is inherited from the parent env t0100: more precise `expr` usage
2009-10-27Rainbows! 0.4.0 v0.4.0
Basic single-threaded EventMachine support is now included. It supports async_synatra[1] via the "async.callback" Rack environment[2]. For EventMachine, we rely on the updated attach/watch API in EventMachine 0.12.10. As Revactor 0.1.5 is now available, our Revactor support now depends on it as it adds the ability to listen on UNIX domain sockets. For developers/QA folks, the integration tests are completely revamped for easier maintenance when new concurrency models are introduced and should also produce TAP-compliant output. The test suite remains highly parallelizable using GNU make. There are immediate plans to expand support for both Rev and EventMachine to support use with threaded application dispatch. Eric Wong (41): rev: remove Revactor-specific workaround README: change ordering of concurrency model listing tests: more correct HTTP/0.9 test test-lib: avoid stalling due to bad FIFO handling rev: fix static file responses under HTTP/0.9 add news bodies to site NEWS.atom.xml tests: avoid needlessly remaking "rainbows" initial EventMachine support tests: hopefully fix stalls in input trailer tests tests: avoid race condition in reopen logs test tests: prefer "RUBY" to lowercased "ruby" tests: common setup and wait_start functions tests: add a TAP producer shell library tests: port all existing tests to TAP library tests: remove symlinks and small files, use Make t9000: bail if run with an unsupported/pointless model tests: allow "make $model" to run tests for that model rev: spell ECONNABORTED correctly rev/evma: move common code for event models into ev_core ev_core: do not drop deferred bodies on graceful quits eventmachine: get basic tests working rev: do not File.expand_path on result of body.to_path eventmachine 0.12.8 passes all tests tests: make large file memory tests more reliable eventmachine: require EM 0.12.10 update gem dependencies in comments/local.mk.sample rev: enforce Rev::VERSION >= 0.3.0 eventmachine: add async_sinatra support tests: only load Revactor tests under 1.9.1 tests: gracefully exit if EventMachine is not available tests: error out if socat + curl aren't reachable thread*: fix MRI 1.8.6 compatibility local.mk.sample: cleanups and minor reorg eventmachine: remove unnecessary ivar assignment eventmachine: document our support of "async_synatra" doc: Update TODO and README tests: generate all dependencies atomically app_pool: update RDoc test-lib: DWIM handling of temp UNIX sockets revactor: require 0.1.5, remove 0.1.4 workarounds gemspec: bump up Unicorn dep version to 0.93.4 [1] http://github.com/raggi/async_sinatra [2] this is not 100% Rack::Lint compatible, but we'll let it slide since there are already folks depending on the async_sinatra gem
2009-10-19Rainbows! 0.3.0 v0.3.0
The major feature of this release is the new DeferredResponse middleware for the Rev-based concurrency model. It should be transparently compatible with non-Rev models, as well. As a pleasant side effect, this change also allows large files to be streamed to the client with Rev as the socket becomes writable instead of slurping the entire file into an IO::Buffer first. Bugfixes to graceful shutdowns support for all concurrency models. The Rev-based model also gets a working heartbeat mechanism (oops!) and fixed HTTP/1.1 pipelining support. Eric Wong (37): app_pool: note it being currently broken with Revactor Revactor tests can sleep more easily tests: sleep.ru handles "Expect: 100-continue" Fix graceful shutdown handling of Thread* models harder DRY setting of rack.multithread test-lib: dbgcat adds headers with key name use timeout correctly to join threads on SIGQUIT Rev: simplification to error handling tests: sleep.ru slurps rack.input stream refactor graceful shutdowns again, harder tests: introduce require_for_model function tests: add unbuffered tee(1)-like helper tests: rack.input trailer tests for all models tests: fix issues with non-portable shell constructs tests: fix random_blob dependency tests: factor out a common parser error "library" tests: DRY setting of the "model" environment var tests: DRY Ruby requires based on model test-lib: quiet down pipefail error message tests: DRY require tests for Rev/Revactor rev: handle fully-buffered, pipelined requests rev: avoid stack overflow through pipelining tests: common basic HTTP tests for all models tests: rack.input hammer concurrency testing tests: for log reopening for all concurrency models http_response: filter out X-Rainbows-* headers rev: fix heartbeat timeouts revactor: switch to a 1 second heartbeat rev: async response bodies with DevFdResponse middleware tests: more reliable error checking tests: DWIM FIFO creation tests: predictable and simpler tempfile management rev: AsyncResponse => DeferredResponse API cleanup rev: update documentation for this model TUNING: update documentation notes TODO: update with new items local.mk.sample: sync with BDFL's version
2009-10-18rev: async response bodies with DevFdResponse middleware
This new middleware should be a no-op for non-Rev concurrency models (or by explicitly setting env['rainbows.autochunk'] to false). Setting env['rainbows.autochunk'] to true (the default when Rev is used) allows (e)poll-able IO objects (sockets, pipes) to be sent asynchronously after app.call(env) returns. This also has a fortunate side effect of introducing a code path which allows large, static files to be sent without slurping them into a Rev IO::Buffer, too. This new change works even without the DevFdResponse middleware, so you won't have to reconfigure your app. This lets us epoll on response bodies that come in from a pipe or even a socket and send them either straight through or with chunked encoding.
2009-10-15Rainbows! 0.2.0 v0.2.0
This release adds preliminary Rev support for network concurrency under Ruby 1.8 and Ruby 1.9. There are caveats to this model and reading the RDoc for Rainbows::Rev is recommended. Rainbows::AppPool Rack middleware is now available to limit application concurrency on a per-process basis independently of network concurrency. See the RDoc for this class for further details. Per-client timeouts have been removed, see http://mid.gmane.org/20091013062602.GA13128@dcvr.yhbt.net for the reasoning. Rack environment changes: * "rack.multithread" is now only true for models with "Thread" in their name. Enabling thread-safe (but not reentrant) code may actually be harmful for Revactor. * "rainbows.model" is now exposed so the application can easily figure out which network concurrency model is in use. Bugfixes include better shutdown and error handling for all existing models, OpenBSD compatibility for the per-process heartbeat (same as found in unicorn v0.93.3). Eric Wong (53): add SIGNALS doc to RDoc SIGNALS: add Rainbows!-specific notes doc: better "Rainbows!" RDoc examples and linkage tests: generate random_blob once for all tests tests: move trash files to their own trash/ directory t0000: basic test includes keepalive + pipelining tests: simplify temporary file management tests: add dbgcat() utility method fchmod heartbeat flips between 0/1 tests: add revactor pipelining/keepalive test thread_spawn: trap EAGAIN on accept_nonblock thread_spawn: more robust loop thread_spawn: non-blocking accept() shouldn't EINTR tests: enable pipefail shell option if possible README for test suite tests: TEST_OPTS => SH_TEST_OPTS tests: update TRACER examples in makefile tests: create a bad exit code by default thread_spawn: clean up nuking of timed-out threads factor out common listen loop error handling graceful exit on trap TypeError from IO.select expand and share init_worker_process revactor: break on EBADF in the accepting actors revactor: cleanups and remove redundancy No need to be halving timeout, already done for us revactor: graceful death of keepalive clients revactor: continue fchmod beat in graceful exit cleanup thread models, threads no longer time out revactor: fix graceful shutdown timeouts Fix graceful shutdowns for threaded models SIGINT/SIGTERM shuts down instantly in workers tests: check for common exceptions with "Error" DEPLOY: update with notes on DoS potential tests: add reopen logs test for revactor vs Unicorn: use diagrams for concurrency models vs Unicorn: fix wording to be consistent with diagrams vs Unicorn: fix copy+paste errors and grammar fail README: alter reply conventions for the mailing list preliminary Rev support local.mk.sample: use ksh93 as default $(SHELL) rack.multithread is only true for Thread* models Rev: general module documentation + caveats Rev: fix error handling for parser errors t3003: set executable bit documentation updates (mostly on network models) rack: expose "rainbows.model" in Rack environment tests: enforce rack.multithread and rainbows.model README: update URLs README: update with Rev model caveats Add Rainbows::AppPool Rack middleware t4003: chmod +x local.mk.sample: use rev 0.3.1 instead README: link to AppPool and extra note about Rev model
2009-10-14rack.multithread is only true for Thread* models
Enabling thread-safe or thread-aware code paths in applications may even be dangerous in some cases and cause deadlocks in code that otherwise does not expect threads. This is especially true of the Revactor case where being a "drop-in" replacement for IO routines is dangerous if a mutex is held while an Actor performs a "blocking" I/O operation. Basically start to assume that anybody writing an app using Rev or Revactor already takes Rev/Revactor concurrency into account and won't need the rack.multithread flag set to do special things.
2009-10-05Rainbows! 0.1.1 v0.1.1
Fixed Ruby 1.8 support (and all 1.9 systems without Revactor). Process-wide timeout handling for the ThreadSpawn concurrency model should now work properly. Small cleanups everywhere. Eric Wong (16): Rakefile: add publish_news target Fix NEWS generation on single-paragraph tag messages README: move RDoc links down to fix gem description README: add install instructions summary: s/slow apps/sleepy apps/g Avoid naming names in LICENSE/README files rainbows/base: cleanup constant include tests: quiet down bin installation Add top-level "test" target for make local.mk.sample: sync to my current version tests: allow "make V=2" to set TEST_OPTS += -x cleanup temporary file usage in tests local.mk.sample: fix revactor dependency Thread* models: cleanup timeout management thread_spawn: fix timeout leading to worker death less error-prone timeouts for Thread models
2009-10-05Rainbows! 0.1.0 v0.1.0
Not using the Unicorn version number with this since it's not remotely close to Unicorn in stability.
2009-10-04doc updates; use "Rainbows!", not "Rainbows"
Also add notes about development things and the configuration language which uses "Rainbows!". Calling ourselves "Rainbows!" will help us be taken even more seriously than if the project were just called "Rainbows"
2009-10-02set "encoding: binary" for all files
2009-10-02initial revision
No tests yet, but the old "gossamer" and "rainbows" branches seem to be basically working.