1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
| | = Rainbows! Unicorn for slow apps and slow clients
\Rainbows! is a HTTP server for {Rack}[http://rack.rubyforge.org/]
applications. It is based on {Unicorn}[http://unicorn.bogomips.org/],
but designed to handle applications that expect long request/response
times and/or slow clients. For Rack applications not heavily bound by
slow external dependencies, consider Unicorn instead as it simpler and
easier to debug.
== \Rainbows! is about Diversity
We aim to support as many concurrency models as we can because they all
suck; differently.
For network concurrency, models we currently support are:
* {:ThreadSpawn}[link:Rainbows/ThreadSpawn.html]
* {:ThreadPool}[link:Rainbows/ThreadPool.html]
* {:Revactor}[link:Rainbows/Revactor.html]
We have {more on the way}[link:TODO.html] for handling network concurrency.
Additionally, we also use multiple processes (managed by Unicorn) for
CPU/memory/disk concurrency.
== Features
* Designed for Rack, the standard for modern Ruby HTTP applications.
* Built on Unicorn, inheriting its process/socket management features
such as transparent upgrades and Ruby configuration DSL.
* As with Unicorn, it is able to stream large request bodies off the
socket to the application while the client is still uploading. Since
\Rainbows! can handle slow clients, this feature is more useful than
it is with Unicorn.
* Combines heavyweight concurrency (worker processes) with lightweight
concurrency (Actors or Threads), allowing CPU/memory/disk to be scaled
independently of client connections. Alternative concurrency models
(listed in the TODO) will be supported as we find time for them.
== Applications
\Rainbows is for the odd things Unicorn sucks at:
* 3rd-party APIs (to services outside your control/LAN)
* OpenID consumers (to providers outside your control/LAN)
* Reverse proxy implementations with editing/censoring
(to upstreams outside your control/LAN)
* Comet
* BOSH (with slow clients)
* HTTP server push
* Long polling
* Reverse Ajax
== License
\Rainbows! is copyright 2009 Eric Wong and contributors. It is based on
Mongrel and Unicorn and carries the same license.
Mongrel is copyright 2007 Zed A. Shaw and contributors. It is licensed
under the Ruby license and the GPL2. See the included LICENSE file for
details.
\Rainbows! is 100% Free Software.
== Usage
=== for Rack applications
In APP_ROOT (where config.ru is located), run:
rainbows
\Rainbows! will bind to all interfaces on TCP port 8080 by default.
=== Configuration File(s)
\Rainbows! will look for the config.ru file used by rackup in APP_ROOT.
For deployments, it can use a config file for Unicorn and
\Rainbows!-specific options specified by the +--config-file/-c+
command-line switch. \Rainbows! accepts all options found in
{Unicorn::Configurator}[http://unicorn.bogomips.org/Unicorn/Configurator.html]
as well as the "\Rainbows!" block, so you can have the following in your
config file:
Rainbows! do
use :Revactor
worker_connections 128
end
== Development
* git: git://git.bogomips.org/rainbows.git
* cgit: http://git.bogomips.org/cgit/rainbows.git
Inline patches (from "git format-patch") to the mailing list are
preferred because they allow code review and comments in the reply to
the patch.
We will adhere to mostly the same conventions for patch submissions as
git itself. See the Documentation/SubmittingPatches document
distributed with git on on patch submission guidelines to follow. Just
don't email the git mailing list or maintainer with \Rainbows! patches.
== Disclaimer
There is NO WARRANTY whatsoever if anything goes wrong, but let us know
and we'll try our best to fix it.
== Contact
All feedback (bug reports, user/development dicussion, patches, pull
requests) go to the mailing list/newsgroup. Patches must be sent inline
(git format-patch -M + git send-email). No subscription is necessary
to post on the mailing list. No top posting. Address replies +To:+ (or
+Cc:+) the original sender and +Cc:+ the mailing list.
* email: mailto:rainbows-talk@rubyforge.org
* archives: http://rubyforge.org/pipermail/rainbows-talk
* subscribe: http://rubyforge.org/mailman/listinfo/rainbows-talk
|