Connessione NGINX + uWSGI Reset da Peer

Question

Sto tentando di ospitare l'applicazione Bottle su NGINX usando uWSGI.

Ecco la mia 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; 
    } 

Io corro uwsgi come questo

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

sto usando POST Request. Per quello che usa dev Http Client. Il che va infinita quando invio la richiesta

http://localhost/myapp 

server di uWSGI riceve la richiesta e stampe

[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) 

ma in nginx log degli errori

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" 

Cosa fare?

Answer 1

Non è possibile inviare dati dal client senza leggerli nell'applicazione. mentre questo non è un problema in uWSGI, nginx fallirà. Puoi "falsificare" la cosa usando l'opzione --post-buffering di uWSGI per leggere automaticamente i dati dal socket (se disponibile), ma è meglio "aggiustare" (anche se non considero un bug) il tuo app

Answer 2

Non utilizzare thread!

Ho lo stesso problema con Global Interpretator Lock in Python sotto uwsgi. Quando non utilizzo il ripristino dei collegamenti non filettati.

Esempio di uwsgi config (1 GB di RAM sul server di)

[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

assicurarsi di consumare i vostri dati post nell'applicazione

per esempio se si dispone di un'applicazione di pitone

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

Questo problema si verifica quando il corpo di una richiesta non viene consumato, dal momento che uwsgi non può sapere se sarà ancora necessario a un certo punto. Quindi uwsgi manterrà i dati fino a quando non sarà consumato o fino a quando nginx non reimposterà la connessione (perché a monte il timeout).

L'autore di uwsgi spiega here:

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 

Quindi, per risolvere questo problema è necessario assicurarsi di sempre o leggere l'intero corpo della richiesta o meno di inviare un corpo se non è necessario (per un ELIMINA esempio).