Mongrel2 1.0beta1 Out. It's A Big One.
- From:
- Zed A. Shaw
- Date:
- 2010-08-23 @ 09:39
Hey Everyone,
I slaved away all last week beefing the tests up so we'd have good
coverage, *just* so I could crank out a fairly large redesign this
weekend. There were two bugs that just couldn't be fixed with the
current design, but which are now fixed and we also get a few nice new
features with this new design.
First, you can grab the latest source tarballs at:
http://mongrel2.org/home
As usual, and the source tree is now tagged with this release:
http://mongrel2.org/taglist
Every release from now on will be tagged and I'll start generating
automated change logs and version numbers for the server responses.
The first big bug was that when a 0MQ handler receives a request, it's
given a connection id that's just the file descriptor. That's easy, but
there's all sorts of race conditions, so when the server was hit hard
with httperf, the connections would mix up and handlers would
accidentally send messages to the wrong connections.
Handlers now get IDs that have nothing to do with the file descriptors,
and are just perpetually increasing numeric ids that loop around after
64k of them pass. That puts an upward limit of 64k connections, but I
can make that configurable. Now it's pretty damn hard to mix up
connections and you shouldn't see any crossover anymore unless you do it
on accident in your handler.
The registration code is completely rewritten to handle this, and
allocates a large fixed array to manage the data so it should be simple
and super fast.
The second big bug was in proxying. The proxy code had a bug similar to
the handler code, but it was even worse because it involved the
coordination of two tasks trying to juggle sending and receiving from
the proxy. This has now been completely rewritten with a totally
different design that keeps everything in one task, uses the state
machine to accurately process proxy requests, and *parses* the response
from the server to keep things accurate. It even handles bonkers
chunked encodings and servers that don't give a content length.
This means that it may be a little faster, might be slower in a few
cases, but definitely uses less resources, is more reliable, and gives
us the ability to parse and filter responses too if we want.
There's also a bug in the JSON encoding that I fixed where if a header
had " or \ chars it would choke receivers. I've got those escaped now
so should be good.
Please grab it and try it. Thanks.
--
Zed A. Shaw
http://zedshaw.com/