Re: [mongrel2] ANN: m2wsgi 0.4.0
- From:
- Loic d'Anterroches
- Date:
- 2011-03-04 @ 07:46
Hi Ryan,
This is great, I am going to reap the reaper and see what could be
reused for Photon. The dispatcher is also interesting. I may be wrong,
but we are going to hit an issue with Mongrel2 in general, the issue
will be the number of processes running at the backend level and chating
with Mongrel2, the handlers and the associated services/tasks.
Experience will tell us the best way to manage all of them.
loïc
On 2011-03-04 02:35, Ryan Kelly wrote:
>
>
> Hi All,
>
>
> I'm pleased to announce version 0.4.0 of m2wsgi, a mongrel=>wsgi
> gateway and collection of helper tools. Code here:
>
> http://pypi.python.org/pypi/m2wsgi/0.4.0
>
>
> This is a pretty big release with lots of refactoring and new
> functionality; anyone upgrading from an older version should definitely
> consult the changelog.
>
>
> Of particular interest to the list might be the "devices" that ship
> with m2wsgi. These are stand-alone programs designed to perform
> specific tasks within a mongrel2 deployment. So far I have:
>
>
> * reaper: a device for timing out dead or hung connections
> * response: a device for sending out canned responses
> * dispatcher: a device for doing clever dispatching and routing
> to a pool of handlers
>
> I hope to extract at least the reaper and response devices into
> mongrel2 core after kicking them around for a while as external
> programs.
>
>
> As a quick example of what the dispatcher device is all about, it lets
> you easily implement "sticky sessions" among a handler pool.
>
> First you connect a dispatcher to mongrel2 and tell it to be sticky:
>
> python -m m2wsgi.device.dispatcher --sticky \
> tcp://127.0.0.1:9999 # mongrel2 req socket \
> tcp://127.0.0.1:8888 # dispatcher output socket
>
> Then you can start any number of handler processes connecting to the
> dispatcher:
>
> for _ in 1 2 3 4 5; do
> python -m m2wsgi --conn-type=dispatcher \
> dotted.path.to.wsgi.app \
> tcp://127.0.0.1:8888
> done
>
>
> And it will route each client connection to a specific handler. The
> handler selection is based on a consistent hash, so it updates
> appropriately as handlers connect or disconnect from the dispatcher at
> runtime.
>
>
> Enjoy!
>
>
> Ryan
>
>