Ich sehe seltsames Verhalten mit dem Code hier .
Client-Seite (Javascript):
%Vor%Server-Seite (C #):
%Vor% Nachdem ich ping gedrückt habe, um der pings -Warteschlange ein neues Element hinzuzufügen, wählt die Schleife innerhalb der Methode Message das neue Element aus und gibt ein Ereignis aus, über Response.Write (bestätigt mit Debug.Print auf der Server). Der Browser löst jedoch onmessage nicht aus, bis ich ein zweites Mal ping drücke, und der Browser gibt ein anderes Ereignis aus; Zu diesem Zeitpunkt erreichen die Daten des ersten -Ereignisses onmessage .
Wie kann ich das beheben?
Um zu verdeutlichen, das ist das Verhalten, das ich erwarten würde:
%Vor%Genau das passiert tatsächlich:
%Vor% (Beim Ausführen in Chrome wird die message -Anfrage auf der Registerkarte "Netzwerk" immer als ausstehend angezeigt. Ich bin mir nicht sicher, ob dies das normale Verhalten von Server-gesendeten Ereignissen ist oder ob es sich auf das Problem bezieht.)
Bearbeiten
Die Zeichenfolgendarstellung der msg -Variable nach Response.Write sieht folgendermaßen aus:
sehr deutlich einschließlich der Zeilenumbrüche.
Dies ist keine Antwort pro sagen, aber hoffentlich wird es eine führen. Ich konnte es mit dem folgenden Code arbeiten.
%Vor% Die Codezeile, die den Unterschied macht, ist der zweite Response.Write . Die Nachricht wird nicht im Browser angezeigt, bis der nächste Ping Ihrem Problem ähnelt, aber der Ping wird immer angezeigt. Ohne diese Zeile erscheint der Ping erst nach dem nächsten Ping, oder sobald mein 30-Sekunden-Zähler abgelaufen ist.
Die fehlende Nachricht, die nach dem 30-Sekunden-Timer erscheint, lässt mich schlussfolgern, dass dies entweder ein .Net-Problem ist oder dass etwas fehlt. Es scheint kein Ereignisquellenproblem zu sein, da die Nachricht auf einem Serverereignis erscheint, und ich hatte keine Probleme mit SSE mit PHP.
Als Referenz finden Sie hier das JavaScript und HTML, mit dem ich getestet habe.
%Vor%Da es sich bei einem Ereignisstrom nur um Textdaten handelt, kann der doppelte Zeilenumbruch vor dem Schreiben des ersten Ereignisses in die Antwort den Client beeinträchtigen. Das Beispiel von mdn docs schlägt
vor %Vor% Was angewendet werden könnte, gilt für die .NET-Antwortbehandlung (beachten Sie die Nebenwirkungen von Response.ClearContent() ).
Wenn es sich zu hackig anfühlt, könnten Sie Ihren Stream mit einem Keep-Alive-Kommentar starten (wenn Sie das Zeitlimit vermeiden möchten, müssen Sie möglicherweise regelmäßig Kommentare senden):
: just a keep-alive comment followed by two line-breaks, Response.Write me first
Das Standardverhalten von .net besteht darin, den Zugriff auf den Sitzungsstatus zu serialisieren. Es blockiert die parallele Ausführung. Anforderungen werden sequenziell verarbeitet und der Zugriff auf den Sitzungsstatus ist für die Sitzung exklusiv. Sie können den Standardstatus pro Klasse überschreiben.
%Vor%Es gibt ein Beispiel dafür in der Frage hier .
BEARBEITEN: Würden Sie bitte versuchen, das Objekt zuerst zu erstellen und es dann an Enqueue zu übergeben? Wie in:
%Vor%Es könnte etwas Seltsames passieren, wenn Dequeue denkt, dass es den Job erledigt hat, aber das PingData-Objekt ist noch nicht richtig konstruiert.
Wir können auch console.log("I made it to the function") anstelle von console.log(e.data) ausprobieren.
---- VORHERIGE INFORMATIONEN, DIE UNTEN ERHALTEN WURDEN ----
Bitte stellen Sie sicher, dass der Server Debug.Print diese Codezeile bestätigt:
%Vor%Wird tatsächlich ausgeführt? Bitte überprüfen Sie dies. Wenn Sie die gesendete Antwort des Servers erfassen können, können wir dann sehen, was es ist?
Könnten wir auch sehen, auf welchen Browsern Sie getestet haben? Nicht alle Browser unterstützen Serverereignisse.
Tags und Links asp.net-mvc javascript server-sent-events