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.
InformationsquelleAutor Eddie | 2009-04-24
Schreibe einen Kommentar