uWSGI Integration

[Jonathan Oliver]

We have a set of use cases where the workloads are highly asynchronous with little to almost no IO and fall in perfectly with the Tornado model and where we are looking to setup an instance of Tornado.  One big question I have is if we can let uWSGI (in async/non-blocking mode) be the container for Tornado.  In some of my initial searches, it appeared as though Tornado needs to be its own web server in order to wireup everything up properly.  Any thoughts on how to make these two excellent pieces of technology play well together?

[Ben Darnell]

The synchronous parts of Tornado can run on uWSGI using
tornado.wsgi.WSGIApplication, but the async parts require the Tornado
HTTPServer. Why do you want to add uWSGI to the mix?

-Ben

[Jonathan Oliver]

I'm really looking for the async part of Tornado.  Ideally, I was looking to have nginx communicate with uwsgi via a binary protocol and then route the request into the Tornado framework.  It appears that this isn't possible at the moment until PEP 444 is adopted and then implemented, so it would appear the easiest thing is to drop uwsgi completely.

[Ben Darnell]

PEP 444 only addresses half of the problem - it would let you use
@tornado.web.asynchronous and RequestHandler.flush() in a WSGI
environment, but because you're not running in an IOLoop you wouldn't
be able to use AsyncHTTPClient, asyncmongo, or other asynchronous
libraries.

Is your interest in uWSGI mainly because of familiarity, or is there
something specific that uWSGI offers that you don't get with Tornado
alone?

-Ben