Is there a reason this would not be the best ever way to serve web-apps?
Has anyone used it in semi-production ?
From an high-availability/scaling point-of-view mongrel2 simply beat every
solution out-there. The choice of using zeromq looked "strange" in the
beginning, but now it has proven being a winning way.
yeah, it (or better said 0mq) automatically handles adding more backend
workers, for example.
also, the decoupling* of the http request and response is very
interesting, although that doesn't map too well in the WSGI world.
*
for people that haven't seen mongrel2, to respond to a request you just
need the the request ID, the handler (a route) UUID, and the address of
the SUB 0mq socket. So you can have one worker get the http request, do
some work, then pass it to another worker, then it could pass to a
third, and the last can respond directly to mongrel2 and its SUB socket.
The sad part is in zed-shaw having left the development of the project, so
its future is not very clear.
It seems that the community has picked it up again. The 1.8 version
should be released any moment now.
In the next months i would like to experiment with zeromq (maybe using it
as a transport for uwsgi packet in http/fastrouter gateways).
cool
--
дамјан
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
