Date | Commit message (Collapse) |
|
kgio 1.2.1 works around a bug for some *BSDs, some of which are
popular platforms for developers.
|
|
We cannot clear the buffer between requests because
clients may send multiple requests that get taken in
one read()/recv() call.
|
|
Internal changes/cleanups for Rainbows!
|
|
Rubinius no longer uses it, and it conflicts with a public
method in MRI.
|
|
This should be easier for Rainbows! to use
|
|
We clobber the accessor methods.
|
|
The parser and request object become one and the
same, since the parser lives for the lifetime
of the request.
|
|
It's more descriptive as to what environment we're setting
than "ENVIRONMENT".
|
|
Since we do those, now.
|
|
Mostly internal cleanups for future versions of Rainbows! and
people trying out Rubinius. There are tiny performance
improvements for Ruby 1.9.2 users which may only be noticeable
with Rainbows!
Unicorn 1.1.x users are NOT required to upgrade.
|
|
We use the latest and greatest whenever possible.
|
|
This also affects some constant scoping rules, but hopefully
makes things easier to follow. Accessing ivars (not via
accessor methods) are also slightly faster, so use them in
the criticial process_client code path.
|
|
This provides the kgio_read! method which is like readpartial,
only significantly cheaper when a client disconnects on us.
|
|
again :x
|
|
TeeInput methods may be invoked deep in the stack, so
avoid giving them more work to do if a client disconnects
due to a bad upload.
|
|
It's expensive to generate a backtrace and this exception
is only triggered by bad clients. So make it harder for
them to DoS us by sending bad requests.
|
|
We don't want to waste time and bandwidth.
|
|
It's a much closer representation of what we'd expect in
the real server than a mono-directional UNIX pipe.
|
|
The bugs from signal handling were fixed in the Rubinius
1.1.0 release.
|
|
This is for compatibility with Ruby implementations such as
Rubinius that use "IO.new" internally inside "IO.open"
|
|
Thanks to kgio, we no longer use accept_nonblock.
|
|
This hopefully makes things easier to read and follow.
|
|
This is slightly shorter and hopefully easier to find.
|
|
This gives us some things to think about.
|
|
This should hopefully make the non-blocking accept()
situation more tolerable under Ruby 1.9.2.
|
|
We'll be using more of Isolate in development.
|
|
This hides more HTTP request logic inside our object.
|
|
This should ensure we have less typing to do.
|
|
Rainbows! will be able to reuse this.
|
|
This hopefully makes things easier to read, follow, and find
since it's mostly documentation...
|
|
There's no need for a response class or object since Rack just
uses an array as the response. So use a procedural style which
allows for easier understanding.
We shall also support keepalive/pipelining in the future, too.
|
|
* commit 'v1.1.4':
unicorn 1.1.4 - small bug fix and doc updates
update Rails 3 tests to use Rails 3 final
avoid unlinking actively listening sockets
doc: update HACKING for documentation contributions
doc: update Sandbox document for Bundler
TUNING: more on socket buffer sizes
|
|
We no longer unlinking actively listening sockets upon startup
(but continue to unlink dead ones). This bug could trigger
downtime and nginx failures if a user makes an error and
attempts to start Unicorn while it is already running.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
There are also minor documentation and test updates pulled in
from master. This is hopefully the last bugfix release of the
1.1.x series.
|
|
Rails 3 is out, and requires no code changes on our end to work
(as far as our tests show :)
(cherry picked from commit da272fc48ffaa808456fe94dd7a3e01bc9799832)
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
(cherry picked from commit 1a2363b17b1d06be6b35d347ebcaed6a0c940200)
|
|
We switched to RDoc 2.5.x long ago and this should clarify
some documentation preferences I have.
(cherry picked from commit 505a9e72d320fe3ae521ceb0f381c1c0f5ae4389)
|
|
Thanks to Lawrence Pit, Jamie Wilkinson, and Eirik Dentz Sinclair.
ref: mid.gmane.org/4C8986DA.7090603@gmail.com
ref: mid.gmane.org/5F1A02DB-CBDA-4302-9E26-8050C2D72433@efficiency20.com
(cherry picked from commit 1a75966a5d1a1f6307ed3386e2f91a28bbb72ca0)
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
|
|
We switched to RDoc 2.5.x long ago and this should clarify
some documentation preferences I have.
|
|
Thanks to Lawrence Pit, Jamie Wilkinson, and Eirik Dentz Sinclair.
ref: mid.gmane.org/4C8986DA.7090603@gmail.com
ref: mid.gmane.org/5F1A02DB-CBDA-4302-9E26-8050C2D72433@efficiency20.com
|
|
Large buffers can hurt as well as help. And the difference
in real apps that do a lot of things other than I/O often
makes it not worth it.
(cherry picked from commit f9a7a19a361fd674bab4e2df7e0897015528bba7)
|
|
Large buffers can hurt as well as help. And the difference
in real apps that do a lot of things other than I/O often
makes it not worth it.
|
|
Rails 3 is out, and requires no code changes on our end to work
(as far as our tests show :)
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
* 1.1.x-stable:
unicorn 1.1.3 - small bug fixes
make log reopens even more robust in threaded apps
update Rails3 tests to use 3.0.0rc2
make log reopens more robust in multithreaded apps
bin/*: more consistent --help output
SIGTTIN works after SIGWINCH
|
|
This release fixes race conditions during SIGUSR1 log cycling.
This bug mainly affects Rainbows! users serving static files,
but some Rack apps use threads internally even under Unicorn.
Other small fixes:
* SIGTTIN works as documented after SIGWINCH
* --help output from `unicorn` and `unicorn_rails` is more consistent
|
|
A follow-up to 4b23693b9082a84433a9e6c1f358b58420176b27
If multithreaded programming can be compared to juggling
chainsaws, then multithreaded programming with signal handlers
in play is akin to juggling chainsaws on a tightrope
over shark-infested waters.
(cherry picked from commit feab35fe531843066db3418598874cf9f9419614)
|
|
A follow-up to 4b23693b9082a84433a9e6c1f358b58420176b27
If multithreaded programming can be compared to juggling
chainsaws, then multithreaded programming with signal handlers
in play is akin to juggling chainsaws on a tightrope
over shark-infested waters.
|
|
No code changes needed, thankfully.
(cherry picked from commit 18968f6aff2fa5ba5a7e3e3d47c9cc05cd6c260d)
|
|
No code changes needed, thankfully.
|