Sockets in CLOSE_WAIT von Jersey Client

Question

Ich verwende Jersey 1.4, die ApacheHttpClient und die Apache MultiThreadedHttpConnectionManager Klasse, um Verbindungen zu verwalten. Für die HttpConnectionManager setze ich staleCheckingEnabled auf true, maxConnectionsPerHost auf 1000 und maxTotalConnections auf 1000. Alles andere ist Standard. Wir laufen in Tomcat und stellen mit dem Jersey-Client Verbindungen zu mehreren externen Hosts her.

Ich habe festgestellt, dass ich nach einer kurzen Zeit beginnen werde, Sockets in einem CLOSE_WAIT-Zustand zu sehen, die mit dem Tomcat-Prozess verbunden sind. Eine Überwachung mit tcpdump zeigt, dass die externen Hosts die Verbindung nach einiger Zeit zu schließen scheinen, aber sie wird an unserem Ende nicht geschlossen. Normalerweise befinden sich einige Daten in der Socket-Lesewarteschlange, oft 24 Bytes. Die Verbindungen verwenden https und die Daten scheinen verschlüsselt zu sein, also bin ich nicht sicher, was es ist.

Ich habe überprüft, um sicherzustellen, dass die ClientRequest-Objekte, die erstellt werden, geschlossen sind. Die Sockets in CLOSE_WAIT scheinen recycelt zu werden und wir haben nicht genug Ressourcen, zumindest zu diesem Zeitpunkt. Ich bin mir nicht sicher, was auf den externen Servern passiert.

Meine Frage ist, ist das normal und sollte ich besorgt sein?

Danke,

John

Answer 1

Dies ist wahrscheinlich ein Gerät wie der Firewall oder das Remote-Server Ablaufen der TCP-Sitzung sein. Sie können Paketerfassung von HTTPS mit Wireshark analysieren, wie auf ihrer SSL-Seite beschrieben:

http://wiki.wireshark.org/SSL

Die staleCheckingEnabled Flagge gibt nur die Prüfung, wenn Sie gehen, um tatsächlich die Verbindung verwenden, damit Sie nicht auf Netzwerkressourcen verwenden (TCP Sitzungen), wenn sie nicht benötigt werden.