about summary refs log tree commit homepage
path: root/lib
DateCommit message (Collapse)
2011-08-05event_machine: add :em_client_class option
This can allow Cramp (and potentially other libraries) to subclass or implement duck-type compatible versions of Rainbows::EventMachine::Client.
2011-07-30Rainbows! 4.1.0 - minor internal cleanups v4.1.0
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).
2011-07-21remove tcp_nodelay/tcp_nopush tweaking
Unicorn 4.x already defaults match those of Rainbows! to favor lower latency instead of lowered bandwidth usage.
2011-07-21remove unnecessary io/wait require
kgio 2.5 added kgio_wait_*able methods
2011-06-29Revert "http_server: cap timeout at 32-bit LONG_MAX seconds"
Unicorn (> 4.0.1) already handles this for us, not that it affects many people... This reverts commit 37c376a9253ed62d134cbb4dbc6eaecc6076c77e.
2011-06-28Fix Fiber* and WriterThread* breakage from removing io/wait
This fixes up breakage introduced in commit 905f0ff393629ddb4d70e3dc221b016128c47415 to switch to kgio for timed, synchronous waiting.
2011-06-28require kgio 2.5 for kgio_wait_readable(timeout)
Since kgio_wait_*able in kgio 2.5 takes an optional timeout argument, we no longer have to load the extra "io/wait" module. This saves us a small amount of some memory and also removes the extra ioctl(FIONREAD) syscall IO#wait enforces. Like IO#wait in Ruby 1.9.3dev, kgio_wait_readable may use ppoll() to wait on high-numbered file descriptors as efficiently as it waits on low-numbered descriptors.
2011-06-27http_server: cap timeout at 32-bit LONG_MAX seconds
We can't wait for longer than 68 years.
2011-06-27Rainbows! 4.0.0 - MOAR concurrency for MOAR COARS v4.0.0
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/
2011-06-27remove unused arg in Rainbows::Response.setup
It hasn't been used in a while, but we kept it for Zbatery version compatibility.
2011-06-22epoll/client: properly close on all pipe responses
Some pipe responses can trigger the on_deferred_write_complete method without ever re-running the event loop. This appears to be the result of the occasional t0050 failures.
2011-06-22dev_fd_response: enable under Rubinius
Untested, but it should work nowadays...
2011-06-22Unicorn 4.x resync for ticker
This removes the extra per-process file descriptor and replaces it with Raindrops.
2011-06-15remove IO_PURGATORY dependency
We no longer need to put all listeners away since Unicorn uses kgio.
2011-06-11configurator: add client_max_header_size directive
Lowering this will lower worst-case memory usage and mitigate some denial-of-service attacks. This should be larger than client_header_buffer_size. The default value is carried over from Mongrel and Unicorn.
2011-06-11doc: remove docs for Rainbows::Fiber::* APIs
Do not encourage their use, really.
2011-06-10stream_response_epoll: update documentation
Yes, this concurrency model is our strangest yet.
2011-06-11remove Rainbows.run method
We can get away with a single stack frame reduction. Unicorn itself has more stack reductions, but Rainbows! is further behind in this area.
2011-06-10ev_core: do not autochunk HTTP/1.0 (and 0.9) responses
Do not assume middlewares/applications are stupid and blindly add chunking to responses (we have precedence set by Rack::Chunked).
2011-06-10ev_core: use add_parse for trailers, too
HttpParser#trailers and #headers are actually the same method, so we'll just continue on.
2011-06-10use HttpParser#add_parse API in Unicorn 3.7.0
It's easier-to-use in some cases.
2011-06-09response: sendfile_range fis for Rack::File in rack 1.3.0
Rack::File already sets Content-Range, so don't repeat work and reparse Content-Length.
2011-06-09stream_response_epoll: our most "special" concurrency option yet
This doesn't use Rainbows::Base so we have no keepalive support at all. This could eventually be an option for streaming applications.
2011-06-09move reopen_worker_logs to base
We may not always use Rainbows! :Base since we don't want keepalive/immediate log reopening in some cases.
2011-05-31xepoll_thread_*: update docs for Linux 3
Linux 3.0.0 is just around the corner and of course newer than 2.6.
2011-05-21use and recommend sleepy_penguin 3.0.1
It's better under 1.9.3 (sleepy_penguin 3.0.1 was bogus)
2011-05-21use and recommend sleepy_penguin 3.0.0
It's better under 1.9.3
2011-05-21try_defer: enable documentation
It should hopefully give this more visibility even though it's an internal feature.
2011-05-21xepoll_thread_pool/client: improve autopush support
We need to trigger a recv() to uncork the response. This won't affect fairness (much) since all recv()s are non-blocking and a successful header parse will put us in the back of the queue.
2011-05-20event_machine: disconnect idle clients at on SIGQUIT
Since it's cheap to maintain keepalive clients with EM, we need a way of disconnecting them in a timely fashion on rare SIGQUIT events.
2011-05-20client: use kgio_write across the board
This should enable Kgio "autopush" support for ThreadSpawn, ThreadPool, XEpollThreadSpawn, and XEpollThreadPool. (still needs tests)
2011-05-20coolio* + *epoll*: drop keepalive clients on SIGQUIT
In concurrency models long keepalive times are cheap (and thus more likely to be used), this allows Rainbows! to gracefully shut down more quickly.
2011-05-20epoll/xepoll: more consistent client implementations
There's less logic in the server this way and easier to potentially share code this way.
2011-05-17doc: recommend io_splice 4.1.1 or later
io_splice 4.1.1 works around issues with socket buffers filling up pipe buffers on blocking splice. See http://lkml.org/lkml/2009/1/13/478 for a better explanation.
2011-05-16Rainbows! 3.3.0 - doc improvements and more v3.3.0
* 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.
2011-05-16writer_thread_*: fix sendfile detection under Ruby 1.8
I can't wait until I stop supporting Ruby 1.8
2011-05-16document RubyGem requirements
Hopefully makes things easier to try out.
2011-05-16doc: cleanup rdoc for Rainbows module
The only supported method is Rainbows.sleep in here
2011-05-16use :pool_size for RLIMIT_NPROC with thread pool models
Only needed for Ruby 1.9
2011-05-16more reliable shutdown for epoll concurrency models
Just close the epoll descriptor, since the sleepy_penguin epoll_wait wrapper may not return EINTR in the future.
2011-05-16add "copy_stream" config directive
This allows using IO::Splice.copy_stream from the "io_splice" RubyGem on recent Linux systems. This also allows users to disable copy_stream usage entirely and use traditional response_body.each calls which are compatible with all Rack servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
2011-05-10configurator: update user-facing documentation
Finally, we have all methods in configurator and it's much easier to document!
2011-05-10max_body: documentation updates
It can't be used as middleware for fully-buffering concurrency models.
2011-05-10configurator: move validation logic over
There's actually no reason we can't have these methods in Rainbows::Configurator where it's easier to document nowadays.
2011-05-09doc: better document :pool_size options
CoolioThreadPool has had it supported forever, but only NeverBlock had it documented.
2011-05-09xepoll_thread_*: add rdoc for users
It's good to describe what they're useful for.
2011-05-09xepoll_thread_spawn/client: remove rdoc
It's an internal implementation detail.
2011-05-09max_body: rdoc updates
speling ficks and less confusing #initialize documentation
2011-05-09xepoll_thread_pool: add optional :pool_size argument
We're now able to configure the number of threads independently of worker_connections.
2011-05-09split out pool_size module
coolio_thread_pool, neverblock both use it, and xepoll_thread_pool will support it next, too.