Was kann die Ursache TCP/IP-Pakete fallengelassen werden sollen, ohne dass die Verbindung?
Ich habe eine web-basierte Anwendung und ein client in Java geschrieben. Für was es Wert ist, das client und server sind sowohl unter Windows. Der client sendet HTTP über Apache HttpClient. Blockiert der server bis zu einer minute, und wenn keine Nachrichten angekommen sind, für die der AUFTRAGGEBER innerhalb dieser minute, gibt der server den HTTP-Statuscode 204 No Content. Ansonsten, sobald eine Nachricht bereit ist, für den Kunden ist, wird er wieder mit dem Körper ein "HTTP 200 OK".
Hier ist, was hat mich verwirrt: Zeitweise für eine bestimmte Teilmenge der Kunden-immer Kunden mit nachweislich unzuverlässigen Netzwerkverbindungen -- der client sendet eine GET-der server empfängt und verarbeitet den GET, aber der Kunde sitzt immer. Aktivieren Sie dabei das debugging-Protokolle für den client, sehe ich, dass HttpClient wartet noch immer auf die erste Zeile der Antwort.
Es ist keine Ausnahme auf dem server, zumindest nichts protokolliert, überall, nicht von Tomcat, nicht durch mein webapp. Laut debugging-logs, dort ist jedes Zeichen, dass der server erfolgreich auf den client reagiert hat. Allerdings zeigt der client keine Zeichen empfangen hatte, nichts. Der client hängt sich auf unbestimmte Zeit in HttpClient.executeMethod. Dies wird offensichtlich, nach der das Zeitlimit für die Sitzung und der Kunde übernimmt die Aktion, die bewirkt, dass ein weiterer Thread um die Ausgabe eines HTTP-POST. Natürlich, die POST schlägt fehl, weil die session abgelaufen ist. In einigen Fällen Stunden verstrichen zwischen die session abläuft und der Kunde die Ausstellung eines POST und die Entdeckung dieser Tatsache. Für diese gesamte Zeit executeMethod
wartet immer noch auf die HTTP-response-Linie.
Wenn ich mit WireShark um zu sehen, was wirklich Los ist auf der wire level, wird dieser Fehler nicht auftreten. Das heißt, dieser Fehler wird auftreten, innerhalb von ein paar Stunden für bestimmte Kunden, aber wenn WireShark läuft an beiden enden, diese gleichen Kunden laufen über Nacht, 14 Stunden, ohne einen Fehler.
Hat jemand sonst begegnet so etwas? Was in der Welt führen kann? Ich dachte, dass TCP/IP-garantierte Paketzustellung auch über Kurzfristige Netzwerk-Störungen. Wenn ich ein SO_TIMEOUT und sofort wiederholen Sie die Anfrage nach timeout, die wiederholen immer gelingt. (Natürlich habe ich zuerst Abbrechen der timed-out-Anfrage und lassen Sie die Verbindung, um sicherzustellen, dass ein neuer sockel verwendet wird.)
Gedanken? Ideen? Gibt es eine TCP/IP-Einstellung zur Verfügung, um Java-oder eine registry-Einstellung in Windows, aktivieren aggressiver TCP/IP-Wiederholungen von verlorenen Paketen?
- Klingt wie die Beobachtung verändert das Ergebnis -> Heisenbug -> etwas mit threading. In diesem Fall klingt es wie jemand geht zu schnell (ich würde mein Geld auf HttpClient) und einfach deadlocks, weil die. Es ist möglich, Sie haben auf einen Fehler in der HttpClient selbst, hoffentlich können andere behilflich sein und Ihnen helfen, mit diesem Problem.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Sind Sie absolut sicher, dass der server erfolgreich gesendet wurde die Antwort auf die clients, die scheinen zu scheitern? Damit meine ich die server gesendet, die Antwort, und der client hat die ack ' ed, die Antwort zurück an den server. Sie sollten sehen, diese mit wireshark auf der server-Seite. Wenn Sie sicher sind, dass dies aufgetreten ist, auf der server-Seite und der client noch immer nicht sehen, alles, was Sie brauchen, um sich weiter oben in der Kette vom server. Gibt es irgendwelche proxy/reverse-proxy-Server oder NAT beteiligt?
Den TCP-transport gilt als ein zuverlässiges Protokoll, aber es nicht garantieren die Lieferung. Die TCP/IP-stack deines OS versuchen ziemlich schwer zu bekommen-Pakete an das andere Ende mithilfe von TCP-Neuübertragungen. Sie sollten sehen, diese in wireshark auf der server-Seite, wenn dies geschieht. Wenn Sie sehen, übermäßige TCP-Neuübertragungen an, es ist in der Regel eine Netzwerk-Infrastruktur-Problem - d.h. schlecht oder falsch konfigurierte hardware/Schnittstellen. TCP-Neuübertragungen an, funktioniert Super für kurze Unterbrechungen der Netzwerkverbindung, aber schlecht in einem Netzwerk mit einer längeren Unterbrechung. Dies ist, weil die TCP/IP-stack sendet nur Neuübertragungen nach dem ein timer abläuft. Dieser timer in der Regel verdoppelt sich nach jedem erfolglosen Weiterverbreitung. Dies ist beabsichtigt, um überschwemmungen zu verhindern, eine bereits problematische Netzwerk mit Neuübertragungen. Wie Sie sich vorstellen können, dies führt in der Regel Anwendungen, die alle Arten von timeout-Probleme.
Je nach Netzwerk-Topologie, müssen Sie möglicherweise auch, um Platz Sonden/wireshark/tcpdump auch an anderen intermediate-Standorte im Netzwerk. Dies wird wahrscheinlich einige Zeit dauern, um herauszufinden, wo die Pakete gegangen sind.
Wenn ich du wäre würde ich weiter beobachten mit wireshark an allen enden, bis das problem erneut Auftritt. Es überwiegend wahrscheinlich. Aber, es klingt wie das, was Sie letztlich finden, ist das, was Sie bereits erwähnt haben - flockige hardware. Wenn die Befestigung der flockig-hardware in Frage, müssen Sie möglicherweise bauen zusätzliche application-level-timeouts und Wiederholungen, um zu versuchen, sich mit dem Thema software. Es klingt wie Sie, ging auf diesem Weg.
Vergessen zu Spülen oder in der Nähe der Buchse auf der host-Seite kann zeitweise haben diesen Effekt für die kurzen Antworten, die je auf timing, die betroffen sein könnten von der Präsenz eines monitoring-Mechanismus.
Besonders vergessen zu schließen, verlassen die Steckdose baumelt, bis die GC kommt, die Rückeroberung es und ruft finalize().
Wenn Sie lange laufen Wird, sollten Sie die timeout auf client-Seite doppelt so schnell wie die server-timeout, wie Sie entdeckt haben.
In einem TCP denen der client eine Nachricht senden, und erwartet eine Antwort, wenn der server abstürzt und neu starten (sagen wir für den point-of-Beispiele) der client würde dann noch warten auf den sockel, bis eine Antwort vom Server, noch der server ist nicht mehr das hören auf das socket.
Wird der client nur entdecken Sie die Buchse geschlossen ist, auf den server zu Ende, wenn es sendet mehr Daten auf diesem socket und der server lehnt diese neuen Daten, und schließt den socket.
Dies ist, warum Sie sollten client-side time-outs auf Anfragen.
Aber Ihr server nicht abstürzt, wenn der server multi-threaded und thread socket für diesen client geschlossen, aber zu der Zeit ( Dauer Minuten) der AUFTRAGGEBER hat eine Konnektivität Ausfall, dann die end-socket-hand-schütteln meine verloren, und als Sie nicht senden mehr Daten an den server von der client-dein client ist wieder einmal hängen gelassen. Dies würde die Band bei Ihrem Abplatzen Anschluss Beobachtung.
Habe ich nicht gesehen, das man per se, aber ich habe ähnliche Probleme mit großen UDP-Datagramme verursacht, IP-Fragmentierung, die führen zu überlastung und letztlich verworfene Ethernet-Rahmen. Da das TCP/IP würde ich nicht erwarten, IP-Fragmentierung ein großes Problem, da es ein stream-basiertes Protokoll ist.
Eine Sache, die ich beachten ist, dass TCP garantiert nicht Lieferung! Das kann es nicht. Was es garantiert ist, dass, wenn Sie senden byte Ein gefolgt von byte B, dann wirst du nie erhalten byte B, bevor Sie Sie erhalten haben byte Ein.
Mit dieser sagte, ich würde die Verbindung der client-Maschine und die überwachung der Maschine zu einem hub. Führen Sie Wireshark auf die überwachung der Maschine, und Sie sollten in der Lage sein zu sehen, was Los ist. Ich habe Probleme in der Beziehung zu beiden whitespace-handling zwischen HTTP-Anfragen und falscher HTTP-chunk-Größen. Beide Probleme wurden durch eine hand geschrieben HTTP-stack, so ist dies nur dann ein problem, wenn Sie mit einem schlechten Stapel.
Könnte diese Computer haben einen virus/malware installiert? Mit wireshark installiert winpcap ( http://www.winpcap.org/ ), die möglicherweise überschreiben die änderungen, die die malware (oder die malware kann einfach erkennen, es wird überwacht, und nicht versuchen, etwas fischig).
Wenn Sie Daten verlieren, ist es höchst wahrscheinlich ein software-bug, entweder im Lesen oder schreiben-Bibliothek.