Error serving aiohttp

[diogobaeder]

Hi,

When trying to serve an aiohttp==0.22.5 application with gunicorn==19.6.0 using the gaiohttp worker class (as documented) I can an error:

Traceback (most recent call last):
  File "/<redacted>/lib/python3.5/site-packages/aiohttp/server.py", line 285, in start
    yield from self.handle_request(message, payload)
  File "/<redacted>/lib/python3.5/site-packages/aiohttp/wsgi.py", line 146, in handle_request
    riter = self.wsgi(environ, response.start_response)
TypeError: __call__() takes 1 positional argument but 3 were given

I noticed that Application.__call__() accepts no parameters, but WSGIServerHttpProtocol.handle_request() tries to call it as a WSGI app (with two arguments, environ and start_response). So I believe Application.__call__() could perhaps accept variable parameters and just ignore them, but I'm not sure this would impact anything else.

However, when following the aiohttp documentation on deploying with Gunicorn, that is, using aiohttp.worker.GunicornWebWorker, then it works fine for me.

[berkerpeksag]

If aiohttp ships with its own worker implementation perhaps we can deprecate ours. Here is the relevant part from http://aiohttp.readthedocs.io/en/stable/gunicorn.html#start-gunicorn:

The custom worker subclass is defined in aiohttp.worker.GunicornWebWorker and should be used instead of the gaiohttp worker provided by Gunicorn, which supports only aiohttp.wsgi applications

[diogobaeder]

Sounds good to me. :-)

[benoitc]

normally people from aiohttp are supposed to update the worker there. @asvetlov has the commit bit. I am wondering now why the worker hasn't been updated there ....

@asvetlov should we deprecate the worker here? Why things changed?

[asvetlov]

Oops. Sorry. I'll update the worker in a few days.

[benoitc]

@asvetlov Thanks! also as of now we don't have to only support wsgi. pure HTTP is ok too :) I will provide more details in the coming month.

[asvetlov]

@benoitc also I want to move aiohttp.wsgi into gunicorn (with keeping a copy in aiohttp for deprecation period).
There are no reasons to keep it in aiohttp itself -- guinicorn is the only user for the module.
Do you have an objection?

P.S.
WSGI support is limited, you know -- async reading of POST body is not allowed.

UPD.
See also aio-libs/aiohttp#1108

[asvetlov]

But deployment aiohttp applications behind gunicorn is quite popular -- people prefer to use it for forking several aiohttp workers with well-known rules.

[asvetlov]

Sorry, it takes more than few days but I didn't give up.
The issue is still in my todo list.
But I should publish new aiohttp release first.

[tilgovi]

@asvetlov we've discussed packaging the workers separately and we have the gunicorn organization on GitHub already. Maybe aiohttp can be the first worker packaged and added to that organization.

[berkerpeksag]

Maybe aiohttp can be the first worker packaged and added to that organization.

+1 from me.

[benoitc]

still. I would appreciate to have the issue fixed. so we can next go further eventually. Any idea of the work to do for it @asvetlov ?