about summary refs log tree commit homepage
path: root/lib/rainbows/ev_core.rb
DateCommit message (Collapse)
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-03s/max_bytes/client_max_body_size/ for consistency
Too confusing otherwise...
2011-05-03add client_header_buffer_size tuning parameter
We're changing our default to 1K buffers to save memory. This should reduce memory usage of idle clients and lower pressure on the MRI GC. Rails applications using session cookies (the default) may want to up this to 2K or more.
2011-01-21ev_core: force input to be given to app_call
No need to setting an ivar for most requests
2011-01-21ev_core: garbage reduction
We don't need to allocate new string objects for short-lived strings. We'll pay the price of a constant lookup instead.
2011-01-20ev_core: simplify setup steps
ev_core is always loaded after forking, so eliminate the need for extra setup steps for each concurrency model that uses it
2011-01-20ev_core: localize 413 error constant
It's the only place we ever use it
2011-01-19remove support for X-Rainbows-* headers
We guarantee the Rack env will exist for the duration of the request/response cycle, so we can just tweak "rainbows.autochunk".
2011-01-17ev_core: reuse buffer to avoid GC thrashing
Single-threaded concurrency models can reuse a single buffer to avoid thrashing memory and causing unnecessary GC activity.
2011-01-11event_machine: buffer reads when waiting for async.callback
We cannot trigger on_read events and invoke the HTTP parser and modify @env while we're waiting for an application to run async.callback. We also need to clear (and *maybe* re-set) @deferred if we're writing from async.callback
2011-01-07event_machine: fold write_response back into client
No point in having too many modules to search around (for both hackers and the runtime).
2011-01-07ev_core: small organization cleanup
We want to put all constants in one place.
2011-01-07more consistent use/avoidance of HeaderHash
Rack::Utils::HeaderHash is still expensive, so avoid forcing it on users since we can assume app/library authors use normally-cased HTTP headers.
2011-01-07favor Hash#include? for some existence checks
Hash#[] is slightly slower on the miss case due to calling Hash#default (but faster for the hit case, probably because it is inlined in 1.9).
2011-01-07ev_core: garbage reduction with const strings
Reading headers is common and we don't want to create new String objects (even if they're tiny or copy-on-write) for the GC to munch on.
2011-01-06event_machine: refactor async.callback for keepalive
async.callback will be useful with Coolio (and more!) soon, so ensure it works as well as the rest of Rainbows!
2011-01-06event_machine: factor out async.callback handling
This will allow Coolio to use it, too.
2011-01-06eliminate G constant and just use the Rainbows! module
Code organization is hard :<
2011-01-04globally refactor Range handling for responses
Rack::Utils::HeaderHash is still very expensive in Rack 1.2, especially for simple things that we want to run as fast as possible with minimal interference. HeaderHash is unnecessary for most requests that do not send Content-Range in responses.
2011-01-04simplify per-client keepalive state checks
This lets us simplify repetitive checks worry less about properly maintaining/closing client connections for each concurrency model we support.
2010-12-09respect client_body_buffer_size in Unicorn 3.1.0
This is only needed for concurrency options that do not use TeeInput, since TeeInput automatically handles this for us.
2010-12-08rev+revactor: fix LARGE pipelined uploads
Large uploads behave differently with regard to buffering, and there were bugs in the way the Rev and Revactor backends handled uploads.
2010-12-03fix pipelining of requests with bodies
All synchronous models have this fixed in unicorn 3.0.1, so only Rev and EventMachine-based concurrency models require code changes.
2010-12-02ev_core: refactor and split cap_input out
Hopefully it makes more sense now and is easier to digest for new hackers.
2010-12-01ev_core: split out prepare_request_body
We may have other uses for this in the future...
2010-10-28rev+event_machine: small cleanups with new parser API
These allow for small reductions in the amount of variables we have to manage, more changes coming with later Unicorns.
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-09-28start using kgio library
It removes the burden of byte slicing and setting file descriptor flags. In some cases, we can remove unnecessary peeraddr calls, too.
2010-07-19rev + em: enable keepalive for pipe/socket responses
This makes it easier to write proxies for slow clients that benefit from keep-alive. We also need to be careful about non-HTTP/1.1 connections that can't do keepalive, now.
2010-07-19rev + em: more easily allow Content-Length in pipe responses
If a response proxying a pipe (or socket) includes a Content-Length, do not attempt to outsmart the application and just use the given Content-Length. This helps avoid exposing applications to weird internals such as env["rainbows.autochunk"] and X-Rainbows-* response headers.
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-28base: constant/namespace cleanup
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-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-02-27ev_core: avoid needless String#dup
Just create an empty string instead and let Unicorn::HttpParser allocate it internally to whatever size is needed.
2009-12-30EventMachine: support deferrables in responses
Some async apps rely on more than just "async.callback" and make full use of Deferrables provided by the EM::Deferrable module. Thanks to James Tucker for bringing this to our attention.
2009-12-16get rid of the magic EvCore.setup
It gets in the way of Rev/EM-based models that won't use EvCore. It doesn't actually do anything useful except making an extra layer of indirection to follow.
2009-12-05ev_core: no need to explicitly close TmpIOs
Just let the GC deal with it
2009-12-05move "async.callback" constant to EvCore
Rev/Packet-based models may support it in the future
2009-11-26cleanup and refactor error handling
Make sure app errors get logged correctly, and we no longer return a 500 response when a client EOFs the write end (but not the read end) of a connection.
2009-11-24rev/event_machine: avoid needless rewinds
No point in rewinding the NULL_IO especially when most requests use them instead of bodies that actually have something.
2009-11-07ev_core: cleanup handling of APP constant
It'll make development of future ev_core-derived things easier, hopefully.
2009-11-06cleanup worker heartbeat and master deathwatch
It turns out neither the EventMachine and Rev classes checked for master death in its heartbeat mechanism. Since we managed to forget the same thing twice, we now have a test case for it and also centralized the code to remove duplication.
2009-11-05ev_core: remove Tempfile usage once again
We're simply too uncomfortable with the weird GC issues associated with Tempfile and having linked temporary files at all. Instead just depend on the #size-aware TmpIO class that Unicorn 0.94.0 provides for us.
2009-11-02ev_core: ensure quit is triggered on all errors
Just in case something goes wrong with the write or the logger, make sure we've triggered a quit.
2009-11-02ev_core: use Tempfile instead of Unicorn::Util::tmpio
Since we're geared towards slower clients, we may be able to make gains from using userspace IO buffering. This allows us to avoid metadef-ing a #size method for every File we allocate and save memory.
2009-11-02Rev model is the only user of deferred_bodies
We don't use it in EventMachine since EM has its own built-in ways to handle deferred bodies.
2009-10-26ev_core: do not drop deferred bodies on graceful quits
Graceful quit means we finish sending everything we have before exiting. Additionally, only signal quits after we've queued the error response up.
2009-10-26rev/evma: move common code for event models into ev_core
EventMachine and Rev models seem to be able to share a lot of common code, so lets share. We may support Packet in the future, too, and end up with a similar programming model there as well.