Sys.WebForms.PageRequestManagerServerErrorException 12031. Keine Ideen mehr

Question

In einem aktuellen Projekt erhalten wir derzeit 12031 Fehler. Hier ist der vollständige Fehler:

Sys.WebForms.PageRequestManagerServerErrorException 12031 der Statuscode, der vom Server zurückgegeben wurde, war 12031

Das Problem ist, dass dies nicht immer passiert und wir den Fehler in der Entwicklungsumgebung nicht reproduzieren können.

Wir verwenden AJAX in unserer Anwendung und diese Ausnahme tritt auf jeder Seite hin und wieder auf.

Ich habe einen Beitrag auf SO mit dem gleichen Problem gefunden und versucht, die maxRequestLength auf "1" setzen, um zu sehen, ob ich ständig den gleichen Fehler erhalte, aber das ist nicht der Fall. Stattdessen erhalte ich

Maximum request length exceeded. 

Ich fange also an zu glauben, dass es nichts mit der maxRequestLength . Mir sind eigentlich die Ideen ausgegangen. Ich habe eine ScriptManager in meinem MasterPage und seine AsyncPostBackTimeout="240" . Das ist die gleiche Zeitspanne (mehr oder weniger). Ich erhalte die Fehlermeldung 12031 nach 3,5 Minuten "Nichts". Ich protokolliere eine der Seiten und mit protokollieren meine ich jeden Abschnitt der Seite wie "Page_Load wird aufgerufen" "xyz wird aufgerufen" usw. und ich habe etwa 15 Stellen auf der Seite dafür. Nachdem der Benutzer auf eine Schaltfläche klickt und ScriptManager versucht, seine Aufgabe zu erfüllen, findet kein Postback statt, und es erfolgt keine Protokollierung. Es ist, als ob die Seite ein Postback machen will, aber zu alt dafür ist. Versucht dies für etwa 3,5 Minuten und scheitert mit dem angegebenen Fehler.

Bitte, wenn Sie eine Idee haben, helfen Sie mir weiter.

Dankeschön

Answer 1

Dieser Fehler hat höchstwahrscheinlich nichts mit der Größe der Antwort, dem AsyncPostBackTimeout oder der maxRequestLength zu tun.

Verbindungsabbrüche sind in der Regel ein Anzeichen für eine schlechte Netzwerkverbindung oder einen Server, der bis an seine Kapazitätsgrenzen ausgelastet ist. Sie können ein paar Dinge ausprobieren:

1. Überprüfen Sie das Windows-Ereignisprotokoll während der Zeit(en), in denen die Kioske bekanntermaßen den Fehler erhalten haben. Suchen Sie nach allen relevanten Fehlern oder Warnungen.
2. Falls möglich, bitten Sie das Kioskpersonal, etwas wie Pingtest um die Qualität ihrer lokalen Netzwerkverbindung zu dem Zeitpunkt zu testen, an dem sie den Fehler in Ihrer App erhalten.
3. Nutzen Sie einen Dienst wie Pingdom um sicherzustellen, dass der Server selbst die Verbindung nicht unterbricht.

Answer 2

Dieser Fehler kann auf die HTTP-Laufzeitbeschränkung der maxRequestLength zurückzuführen sein. Der Standardwert ist 4096.

 Try adding (or editing) the following entry in your Web.Config: 
"<httpRuntime maxRequestLength="8192"  />" (effectively allowing 8mb of data transmission, instead of the default 4mb). 

Bitte nicht....Sie können die Daten nach Ihren Wünschen einstellen. 8192 ist nicht die Grenze. Außerdem müssen Sie Page.Form.Attributes.Add("enctype", "multipart/form-data"); im Page_Load-Ereignis der Seite hinzufügen.

Sie müssen dies im Abschnitt System.Web-Konfiguration eingeben.

Wie kann ich vermeiden, dass eine PageRequestManagerParserErrorException auftritt?

Tun Sie zunächst einmal nichts von dem, was in der vorangegangenen Liste steht! Hier ist eine passende Liste, wie man einen bestimmten Fehler vermeiden kann (wenn möglich): Aufrufen von Response.Write(): Platzieren Sie ein oder ein ähnliches Steuerelement auf Ihrer Seite und setzen Sie dessen Eigenschaft Text. Der zusätzliche Vorteil ist, dass Ihre Seiten gültiges HTML sind. Wenn Sie Response.Write() verwenden, erhalten Sie in der Regel Seiten, die ungültiges Markup enthalten.

Reaktionsfilter: Die Lösung könnte einfach darin bestehen, den Filter nicht zu verwenden. Sie werden ohnehin nicht sehr oft verwendet. Wenn möglich, filtern Sie Dinge auf der Steuerungsebene und nicht auf der Antwortebene.

HttpModules:Gleich wie die Antwortfilter.

Server-Trace ist aktiviert: Verwenden Sie eine andere Form der Ablaufverfolgung, z. B. das Schreiben in eine Protokolldatei, das Windows-Ereignisprotokoll oder einen benutzerdefinierten Mechanismus. Aufrufe von Server.Transfer(): Ich bin mir nicht ganz sicher, warum die Leute überhaupt Server.Transfer() verwenden. Vielleicht ist es eine Altlast aus dem klassischen ASP. Ich würde vorschlagen, Response.Redirect() mit Query-String-Parametern oder seitenübergreifendem Posting zu verwenden.

Eine weitere Möglichkeit, den Parse-Fehler zu vermeiden, besteht darin, ein reguläres Postback anstelle eines asynchronen Postbacks durchzuführen. Wenn Sie z.B. eine Schaltfläche haben, die unbedingt eine Server.Transfer() ausführen muss, lassen Sie sie reguläre Postbacks ausführen. Es gibt mehrere Möglichkeiten, dies zu tun: Am einfachsten ist es, die Schaltfläche einfach außerhalb eines UpdatePanels zu platzieren. Leider lässt das Layout Ihrer Seite dies möglicherweise nicht zu. Fügen Sie einen PostBackTrigger zu Ihrem UpdatePanel hinzu, der auf die Schaltfläche zeigt. Dies funktioniert gut, wenn die Schaltfläche statisch durch Markup auf der Seite deklariert ist. Rufen Sie ScriptManager.RegisterPostBackControl() auf und geben Sie die betreffende Schaltfläche an. Dies ist die beste Lösung für Steuerelemente, die dynamisch hinzugefügt werden, z. B. innerhalb einer sich wiederholenden Vorlage.

Viel Glück!

Answer 3

Ich habe diesen Fehler schon einmal erhalten, als wir ein Barracuda-Gerät vor unserer Website sitzen. Es handelte sich um ein Problem mit der maximalen Anfragelänge, da Barracuda vor einer Überlastung der Anfragegröße schützt. Wir haben das Gerät vorübergehend entfernt und das Problem damit gelöst. Ich bin nicht sicher, ob dies Ihr Problem ist.