Beenden eines uwsgi-Arbeiters programmgesteuert

In meiner Anwendung muss ich ein HTTP-Timeout "simulieren". Einfach gesagt, in diesem Szenario:

client -> myapp -> server 

client macht eine HTTP-POST-Verbindung zu myapp die es an den server . Der server reagiert jedoch nicht aufgrund von Netzwerkproblemen oder ähnlichen Problemen. Ich stecke mit einer offenen TCP-Session vom client die ich ablegen muss.

Meine Anwendung verwendet web.py, nginx und uwsgi.

Ich kann nicht einen benutzerdefinierten HTTP-Fehler wie 418 I am a teapot – es muss ein Verbindungs-Timeout sein, um das Verhalten des server so genau wie möglich zu spiegeln.

Eine Hack-y-Lösung könnte (ich glaube), um nur time.wait() bis client trennt, aber das würde einen uwsgi-Thread verwenden und ich habe das Gefühl, dass es zu Ressourcen-Hunger führen könnte, weil ein server Timeout wahrscheinlich für andere Verbindungen passieren wird . Ein weiterer Ansatz wird hier darauf hingewiesen , aber diese Lösung bedeutet, dass etwas an den client , was nicht mein Fall ist.

Also meine Frage ist: uwsgi es eine elegante Art, einen uwsgi Arbeiter programmatisch aus Python-Code zu töten?

Bisher habe ich gefunden

  • set_user_harakiri(N) die ich mit einem time.sleep(N+1) kombinieren könnte. Doch in diesem Szenario erkennt uwsgi die Harakiri und versucht, den Arbeiter neu zu produzieren.
  • worker_id() aber ich bin mir nicht sicher, wie ich damit umgehen soll – ich kann nicht viel Dokumentation finden
  • Ein Vorschlag zur Verwendung von connection_fd() wie hier erklärt
  • disconnect() was scheint nichts zu tun, wie der Code fortsetzt und kehrt zum client
  • suspend() suspendiert die Instanz, aber NGINX gibt die Kesselplattenfehlerseite zurück

Irgendeine andere idee

AKTUALISIEREN

Stellt sich heraus, es ist komplizierter als das. Wenn ich gerade den Sockel schließe oder von uwsgi trennen, erkennt der nginx Webserver einen 'Serverfehler' und gibt eine 500 Kesselplattenfehlerseite zurück. Und ich weiß nicht, wie man nginx sagen muss, dass er so nützlich ist.

One Solution collect form web for “Beenden eines uwsgi-Arbeiters programmgesteuert”

Die Antwort ist eine Kombination von beidem.

  1. Von der Python-App, Rückkehr 444
  2. Konfiguriere nginx, wie auf dieser Antwort erklärt, dh mit der uwsgi_intercept_errors Direktive.
  • Hochladen & Encoding .xls Datei Python Web.py
  • Vererbung in web.py?
  • Mit web.py als nicht blockierenden http-Server
  • Dateien, die serviert werden, sind veraltet / zwischengespeichert; Python als fcgi + web.py + nginx
  • UWSGI + NGINX 502 Bad Gateway
  • Wie kann man die Sitzungsdaten im automatisierten Test initialisieren? (Python 2.7, webpy, nosetests)
  • Ändern des statischen Verzeichnispfads in webpy
  • Python web.py Web-Service mehrere Parameter Abfrage nicht funktioniert
  • Web.py auf Google App Engine
  • Globale Variablenverwendung mit web.py in Apache
  • Session in webpy - Benutzernamen in allen Klassen
  • Python ist die beste Programmiersprache der Welt.