2012-10-25 14 views
7

Ich versuche, Flaschenanwendung auf NGINX mit uWSGI zu hosten.NGINX + uWSGI Verbindung durch Peer zurücksetzen

Hier ist mein 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; 
    } 

Ich bin mit uwsgi wie dieses

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

I POST anfordern bin mit. Dafür benutze dev Http Client. Welche geht unendlich, wenn ich die Anfrage

http://localhost/myapp 

uwsgi Server die Anforderung und druckt

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

aber in nginx Fehlerprotokoll

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" 

Was tun, erhält schicken?

Antwort

6

Sie können keine Daten vom Client senden, ohne sie in Ihrer Anwendung zu lesen. Während dies in uWSGI kein Problem ist, wird nginx fehlschlagen. Sie können das Ding mit der Option --post-buffering von uWSGI "fälschen", um automatisch Daten aus dem Socket zu lesen (falls verfügbar), aber Sie sollten besser "reparieren" (auch wenn ich das nicht für einen Fehler halte) App

+0

Ich habe bereits versucht --post-buffering 32768. Immer noch nicht funktioniert –

+2

konsumieren Sie die Post-Daten in Ihrer App? – RickyA

1

Keine Threads verwenden!

Ich habe dasselbe Problem mit Global Interpretator Lock in Python unter uwsgi. Wenn ich nicht threads-nicht Verbindung zurückgesetzt.

Beispiel uwsgi config (1 GB RAM auf dem Server)

[[email protected] 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 
5

stellen Sie sicher, Ihre Post-Daten in Ihrer Anwendung

zum Beispiel verbrauchen, wenn Sie eine Python-Anwendung haben

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") 
+1

Dies löste das Problem für mich auf eine nginx-uwsgi-Django-Implementierung endgültig. Ich baute eine Stub-Ansicht und kümmerte mich zunächst nicht um das eingehende XML. Kleines eingehendes XML würde funktionieren, aber größere würden das Zurücksetzen durch Peer erhalten. Nachdem ich die Ansicht "body = request.body" hinzugefügt hatte, begannen Posts jeder Größe zu arbeiten. – bskinnersf

+2

Dies war auch das Problem für mich auf Django/UWSGI/Nginx-Stack. Ich wusste nicht, dass das eine Sache war. Gibt es Dokumentation/Ressourcen dazu? Warum muss ich die POST-Daten konsumieren?Edit: Einige Details (wenn auch sehr vage) hier: http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html –

3

Dieses Problem tritt auf, wenn der Hauptteil einer Anfrage nicht konsumiert wird, da uwsgi nicht wissen kann, ob es zu einem bestimmten Zeitpunkt noch benötigt wird. So wird sich uwsgi weiter an den Daten halten, bis sie verbraucht sind oder bis nginx die Verbindung zurücksetzt (weil Upstream abgelaufen ist).

Der Autor von uwsgi erklärt es 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 

Also dieses Problem zu beheben Sie immer entweder sicherstellen müssen, den gesamten Anforderungstext lesen oder nicht, einen Körper zu senden, wenn es nicht notwendig ist (für eine LÖSCHEN Sie zB).

+0

Das hat sehr geholfen! Vielen Dank! – vincent

Verwandte Themen