| Date | Commit message (Collapse) |
|---|
|
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
|
|
Avoid calling chmod on "false" leading to NoMethodError
and rely entirely on LISTENERS.first being valid.
|
|
|
|
Ensure we reset the per-thread time Thread.current[:t] with each
connection so we don't timeout long-lived connections.
|
|
This makes the Ruby 1.9 tests take much longer now, ~14s
because the SHA1 test is fairly intensive.
|
|
mktemp(1) requires files to end with "XXXXXXXX", not just have
that template anywhere. Also, add pid files to the TEST_RM_LIST
since test failures can leave a pid file dangling. Lastly,
since the config.ru files are 100% static, just check them
as standalone files in instead of allocating a tempfile on them
for easier maintenance.
|
|
Normally we can run "make V=1" for medium verbosity
|
|
This allows the "full-test" target to run 1.9 and 1.8 tests
together and sets up gem paths so I don't have to load rubygems.
Currently I can run "make -j full-test" in 5.3 seconds on my
box vs ~20 seconds without the "-j". Hopefully this time
continues to stay low as more tests are added...
|
|
|
|
|
|
This was breaking badly under 1.8 since Revactor couldn't be
included (the constant is listed once it is declared as an
autoload).
|
|
Everything is logged in git anyways and it'll be easier to
hand off to somebody else.
|
|
I think "sleepy" is a better term than "slow" here. "slow" can
mean apps that are CPU/memory bandwidth-bound, and Rainbows!
sucks at those.
|
|
|
|
|
|
commit 2643f9c34a4fc63ab9533d851a564be93dcc8bdb from
Unicorn
|
|
|
|
Not using the Unicorn version number with this
since it's not remotely close to Unicorn in stability.
|
|
We'll be able to use the SHA1 test in other places, too.
|
|
|
|
Only inject this method into Unicorn::Configurator to avoid
polluting the namespace.
|
|
Various concurrency models work and scale differently, pick
counts that make a reasonable amount of sense...
|
|
This is somewhat like the original model found in Mongrel,
except we refuse to accept() connections unless we have slots
available. Even though we support multiple listen sockets, we
only accept() synchronously to simplify processing and to avoid
having to synchronize ThreadGroup management.
|
|
I'd rather write shell scripts in shell than shell scripts in
Ruby like was done with Unicorn. We're a *nix-only project so
we'll embrace *nix tools to their fullest extent and as a
pleasant side-effect these test cases are immune to internal API
changes.
|
|
It's usually a bad sign if we have unhandled exceptions in
the listener loops, so we'll exit just in case.
|
|
While we're at it, make it properly 100% message-driven so
there's no more busy-waiting and polling for dead actors, No we
just wait for client actors to die off and resume listener
actors if they stopped accepting.
|
|
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"
|
|
|
|
Revactor may be gaining support for UNIX domain socket listeners
soon, so factor out revactorize_listeners into its own method
that can conditionally handle UNIX domain sockets if our
Revactor version supports it.
Patch for Revactor submitted here:
http://rubyforge.org/pipermail/revactor-talk/2009-October/000035.html
|
|
:Base is default (along with the implied worker_connections=1).
This disallows nil for worker_connections, and makes.
|
|
|
|
So are Thread#terminate! and Thread#exit!, so we use
Thread#kill instead.
|
|
They're similar enough (especially as far as the constants go)
and allows a :Base to be used which basically acts like plain
Unicorn but with HTTP keepalive + pipelining support
|
|
Patch submitted upstream:
http://rubyforge.org/pipermail/revactor-talk/2009-October/000034.html
|
|
This allows the server to be configured by doing something like
this inside an existing Unicorn configuration file:
Rainbows! do
use :Revactor
worker_connections 50
end
This should make it obvious we're using Rainbows-only features.
|
|
I didn't remember extend when this was originally implemented.
|
|
This should make it easier to maintain/read configs that
are Rainbows-specific
|
|
|
|
|
|
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|