2012-12-27 4 views
6

Ich habe einen seltsamen Fehler mit Django-Sitzungen in meiner App: einige Male (ca. 10 mal für ~ 20000 pro Tag) Sitzungsinformationen für Benutzer gelöscht wird. Ich habe es über Protokolldateien verfolgt: auf Seite A gibt es Informationen für die Sitzung des Benutzers, nachdem er das Formular übermittelt und auf der nächsten Seite seine Sitzung leer ist. Ich habe zwei Arten von Speicher versucht: memcached + db und db nur und dieses Problem gilt für beide. Ich habe versucht, diese Szenarien zu reproduzieren, aber alles funktioniert wie erwartet, es passiert sehr selten. Ich habe auch überprüft, dass dieses Problem für verschiedene Benutzer existiert, und für sie wird nicht jedes Mal reproduziert. Ich habe keine Ideen, wie ich die Ursache herausfinden kann und ich weiß nicht, was sonst noch hier als Beschreibung steht. Wenn jemand Ideen hat, lass es mich wissen. Wenn es wichtig ist, verwende ich meine App mit django 1.2 + FastCGI. Danke!Schwieriges Problem mit Django-Sitzungen: manchmal Sitzungsinformationen gelöscht

UPD: Ich überprüfte und sehe, dass Sitzungsschlüssel von Verwendungen nicht während zwei sequenziellen Anforderungen geändert wird, auf erste Anforderung gibt es einen tatsächlichen Sitzungszustand, und in der zweiten Sitzung Variablen mit leer zurückgesetzt werden.

+0

Verwenden Sie ein Javascript, das eine gleichzeitige Anfrage erstellen kann, damit beide die Sitzung ändern können? – hynekcer

+0

@hynekcer, keine Sitzungen werden in Aufrufen von JS nicht aktualisiert. – dbf

+0

Sind Sie sicher, dass Sie Multithreading in FastCGI nicht verwenden? (Wenn Sie FCGI_MAX_CONNS = 1, FCGI_MAX_REQS = 1, FCGI_MPXS_CONNS = 0 setzen, können Sie sicher sein, nur einzelne Threads zu verwenden, unabhängig davon, welche Fastcgi-Implementierungen Sie verwenden: [FastCGI-Spezifikation] (http://www.fastcgi.com/drupal/node/6? q = node/22)) Dann empfehle ich, die Prozess-ID zu protokollieren, um zu sehen, ob sie nur durch denselben Prozess oder nur durch einen anderen Prozess gelöscht werden kann. (Verwenden Sie "% (process) d" in der Protokollformat-Zeichenfolge oder die "os.getpid()" -Funktion.) – hynekcer

Antwort

4

Als ein Weg, um dieses Problem zu debuggen, würde ich die Standard-Django-Session-Middleware-Unterklasse (oder was auch immer Sie verwenden zur Zeit):

django.contrib.sessions.middleware.SessionMiddleware

und wickeln process_request und (wahrscheinlich noch wichtiger ist) process_response in etwas zusätzliches Protokollieren. Dann installieren Sie Ihre unterklassierte Sitzung Middleware in der MIDDLEWARE_CLASSES, anstatt die Aktie Django eins.

Sie können auch validieren, dass session.save() seine Änderungen tatsächlich vorgenommen hat, indem Sie versuchen, es zurück zu lesen. Es könnte sein, dass das Problem in der Serialisierung des Sitzungsstatus liegt und dass ein bestimmter Schlüssel oder Wert, den Sie speichern möchten, nicht funktioniert.

Nichts davon wird Ihr Problem beheben, aber es könnte Ihnen helfen festzustellen, was vor sich geht.

4

Wie @steve Mayne erwähnt, wäre es gut, einige Protokollierung der Sitzungen Middleware und Sitzungen Modell speichern Methode zu tun. Das ist etwas womit ich anfangen würde.

Darüber hinaus möchte ich sagen, dass dies ein Datenbankproblem sein könnte, besonders wenn Sie das MySQL-Datenbank-Backend für Sitzungen verwenden. Sie können das Protokoll auf Datenbanksperren und andere Nebenläufigkeitsprobleme überprüfen. Ich musste mich vorher mit ähnlichen Problemen auseinandersetzen und die Lösung ist klar: Optimierung und zusätzliche Leistung.

Wenn Sie eine bestimmte Anwendungs-Middleware haben, können Sie nach Funktionen suchen, die Django-Sitzungen stören. Solche parallelen Operationen können Probleme verursachen, wenn sie nicht ordnungsgemäß implementiert werden.

Eine andere Sache, die ich tun würde, ist auf die neueste stabile Version von Django zu aktualisieren und zu einem mod_wsgi-Setup zu migrieren.

Verwandte Themen