Restablecimiento de la conexión NGINX+uWSGI por pares

bottle

Question

Estoy tratando de alojar Bottle Application en NGINX usando uWSGI.

Aquí está mi nginx.conf

location /myapp/ {
        include uwsgi_params;
        uwsgi_param X-Real-IP $remote_addr;
        uwsgi_param Host $http_host;
        uwsgi_param UWSGI_SCRIPT myapp;
        uwsgi_pass 127.0.0.1:8080;
    }

Estoy ejecutando uwsgi como esto

uwsgi --enable-threads --socket :8080 --plugin python -- wsgi-file ./myApp/myapp.py

Estoy usando POST Request. Para eso usando Dev Http Client. Que va infinito cuando envío la solicitud

http://localhost/myapp

El servidor uWSGI recibe la solicitud e imprime

[pid: 4683|app: 0|req: 1/1] 127.0.0.1 () {50 vars in 806 bytes} [Thu Oct 25 12:29:36 2012] POST /myapp => generated 737 bytes in 11 msecs (HTTP/1.1 404) 2 headers in 87 bytes (1 switches on core 0)

pero en el registro de errores nginx

2012/10/25 12:20:16 [error] 4364#0: *11 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: localhost, request: "POST /myApp/myapp/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:8080", host: "localhost"

¿Qué hacer?

Answer 1

No puede publicar datos del cliente sin leerlos en su aplicación. aunque esto no es un problema en uWSGI, nginx fallará. Puede ''falsificar'' la cosa usando la opción --post-buffering de uWSGI para leer automáticamente los datos del socket (si está disponible), pero será mejor que "corrija" (incluso si no lo considero un error) su aplicación

Answer 2

¡No usar hilos!

Tengo el mismo problema con Global Interpretator Lock en Python bajo uwsgi. Cuando no uso hilos, no restablecimiento de conexión.

Ejemplo de configuración uwsgi (1Gb Ram en el servidor)

[root@mail uwsgi]# cat myproj_config.yaml 
uwsgi:
    print: Myproject Configuration Started
    socket: /var/tmp/myproject_uwsgi.sock
    pythonpath: /sites/myproject/myproj
    env: DJANGO_SETTINGS_MODULE=settings
    module: wsgi
    chdir: /sites/myproject/myproj
    daemonize: /sites/myproject/log/uwsgi.log
    max-requests: 4000
    buffer-size: 32768
    harakiri: 30
    harakiri-verbose: true
    reload-mercy: 8
    vacuum: true
    master: 1
    post-buffering: 8192
    processes: 4
    no-orphans: 1
    touch-reload: /sites/myproject/log/uwsgi
    post-buffering: 8192

Answer 3

asegúrese de consumir sus datos de publicación en su aplicación

por ejemplo, si tienes una aplicación de Python

def my_view(request):

    # ensure to read the post data, even if you don''t need it
    # without this you get a: failed (104: Connection reset by peer)
    data = request.DATA

    return HttpResponse("Hello World")

Answer 4

Este problema ocurre cuando el cuerpo de una solicitud no se consume, ya que uwsgi no puede saber si aún será necesario en algún momento. Así, uwsgi seguirá reteniendo los datos hasta que se consuman o hasta que nginx restablezca la conexión (porque se agotó el tiempo de espera).

El autor de uwsgi lo explica aquí :

08:21 < unbit> plaes: does your DELETE request (not-response) have a body ?
08:40 < unbit> and do you read that body in your app ?
08:41 < unbit> from the nginx logs it looks like it has a body and you are not reading it in the app
08:43 < plaes> so DELETE request shouldn''t have the body?
08:43 < unbit> no i mean if a request has a body you have to read/consume it
08:44 < unbit> otherwise the socket will be clobbered

Por lo tanto, para solucionar esto, debe asegurarse de leer siempre el cuerpo completo de la solicitud o no enviar un cuerpo si no es necesario (para un DELETE, por ejemplo).