Date | Commit message (Collapse) |
|
This release depends on Unicorn 0.96.1 for an updated
Unicorn::HttpParser to avoid leaking memory.
The HttpParser in Unicorn <= 0.96.0 did not setup the parser
object properly to be freed by the garbage collector.
While this bug did not affect Unicorn itself, Rainbows!
allocates a new Unicorn::HttpParser object for every new client
connection and Unicorn did not properly setup the parser object
to be freed by the Ruby garbage collector.
There are also minor cosmetic cleanups and fixes:
Eric Wong (10):
http_response: disallow blank, multi-value headers
Fix "rainbows -h" and "rainbows -v"
Update docs + tests to reflect Rev 0.3.2 release
local.mk.sample: bump Rack dependency
Merge branch 'rack-1.1'
add Cramp integration tests
Rakefile: autoload Gem
t/bin/*: encoding should be the first line after shebang
gemspec: bump dependency on Unicorn to avoid leak
Rainbows! 0.90.2
|
|
The HTTP parser in Unicorn <= 0.96.0 did not use the Ruby API
correctly. While this bug did not affect Unicorn itself,
Rainbows! allocates a new Unicorn::HttpParser object for every
client connection and Unicorn did not properly setup the parser
object to be freed.
|
|
Ruby 1.9 will complain otherwise
|
|
easier to manage for cases where rake isn't a gem itself
|
|
Tested with cramp-0.7 and eventmachine 0.12.10
|
|
* rack-1.1:
http_response: disallow blank, multi-value headers
|
|
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
Do not identify ourselves as "Unicorn", especially not
for -v. Also "ENVIRONMENT" should be "RACK_ENV".
|
|
The HeaderHash optimizations in Rack 1.1 interact badly with
Rails 2.3.5 (and possibly other frameworks/apps) which set
multi-value "Set-Cookie" headers without relying on the proper
methods provided by Rack::Utils.
While this is an issue with Rails not using properly, there
may be similar apps that make this mistake and Rack::Lint
does not guard against it.
Rack-ML-Ref: <20100105235845.GB3377@dcvr.yhbt.net>
|
|
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.
|
|
EM::Deferrables done, NeverBlock updates...
|
|
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.
|
|
We may be making some changes to Unicorn 0.97.0
and allow us to share more code.
|
|
Under all MRI 1.8, a blocking Socket#accept Ruby method (needs
to[1]) translate to a non-blocking accept(2) system call that may
wake up threads/processes unnecessarily. Unfortunately, we
failed to trap and ignore EAGAIN in those cases.
This issue did not affect Ruby 1.9 running under modern Linux
kernels where a _blocking_ accept(2) system call is not (easily,
at least) susceptible to spurious wakeups. Non-Linux systems
running Ruby 1.9 may be affected.
[1] - using a blocking accept(2) on a shared socket with
green threads is dangerous, as noted in
commit ee7fe220ccbc991e1e7cbe982caf48e3303274c7
(and commit 451ca6997b4f298b436605b7f0af75f369320425)
|
|
working_directory and Worker#user got added over time, so
recommending Dir.chdir and Process::UID.change_privilege
is bad.
|
|
Unicorn 0.96.x should be released once Rack 1.1 is out.
|
|
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.
|
|
|
|
|
|
We'll export this across the board to all Rack applications
to sleep with. This provides the optimum method of sleeping
regardless of the concurrency model you choose. This method
is still highly not recommended for pure event-driven models
like Rev or EventMachine (but the threaded/fiber/actor-based
variants are fine).
|
|
|
|
|
|
Thanks to Ben Sandofsky for the extra set of eyes
|
|
Or it'll confuse them more... Really, it does not
matter what the shebang points to as long as long as
setup.rb can deal with it.
|
|
|
|
|
|
|
|
This is like the traditional FiberSpawn, but more scalable (but
not necessarily faster) as it can use epoll or kqueue.
|
|
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.
|
|
Oops.
|
|
TeeInput may explicitly close on client disconnects to
avoid error messages being written to the socket, likewise
with "hack.io" users.
|
|
|
|
|
|
|
|
This makes them easier to override in subclasses.
|
|
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.
|
|
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
|
|
|
|
|
|
* cleanup NEWS.atom.xml feed
* add freshmeat update task
|
|
|
|
Not enough time or interest at the moment to get this
fully working...
|
|
This exposes a client IO object directly to the underlying
application.
|
|
|
|
We no longer explicitly close @input
|
|
EM.defer and EM Deferrables aren't the same thing,
guess we'll have to figure out how to support both.
|