2014-01-20 5 views
16

Wie ist der kürzeste Weg zum Konfigurieren des Verbindungsleerlauf-Timeouts auf der Version Apache HttpClient 4.3?Apache HttpClient 4.3 - Verbindungsleerlauf-Timeout einstellen

Ich habe in der Dokumentation nachgeschaut und konnte nichts finden. Mein Ziel ist es, offene Verbindungen auf einen minimalen Post-Server-Peak zu reduzieren.

zum Beispiel in Jetty-Client 8.x können Sie httpClient.setIdleTimeout gesetzt: http://download.eclipse.org/jetty/stable-8/apidocs/org/eclipse/jetty/client/HttpClient.html#setIdleTimeout(long)

Antwort

29

Der Timeout wird in der RequestConfig, so dass Sie den Standard einstellen könnten, wenn die HttpClientBuilder genannt wird.

Zum Beispiel Ihre Timeout-Variable unter der Annahme ist in Sekunden, um Ihre Gewohnheit zu erstellen RequestConfig Sie so etwas tun könnte: Sie könnten

RequestConfig config = RequestConfig.custom() 
    .setSocketTimeout(timeout * 1000) 
    .setConnectTimeout(timeout * 1000) 
    .build(); 

dann bauen Sie Ihre Httpclient den Standard RequestConfig wie diese Einstellung:

HttpClients.custom() 
    .setDefaultRequestConfig(config); 
+1

Das ist nicht, was ich suche. Das obige ist readTimeout und connectTimeout. Ich versuche herauszufinden, wie man die "Räumungs" -Politik auf die geöffneten Verbindungen setzt. Berücksichtigen Sie eine Spitze, bei der Sie 1000 Verbindungen pro Adresse erreichen. Wie weisen Sie den Apache-Client an, inaktive Verbindungen nach X Sekunden zu schließen? – YaOg

+0

Sie sollten sich vielleicht setKeepAliveStrategy() ansehen, wenn Sie den HttpClient erstellen und eine ConnectionKeepAliveStrategy-Schnittstelle implementieren. Das teilt dem Client mit, wie lange die Verbindung inaktiv sein kann, bevor sie wiederverwendet wird. – Brett

+1

Diese Antwort ist falsch. setConnectTimeout legt das Zeitlimit für die Verbindung mit dem Server fest. setSocketTimeout legt das Zeitlimit während einer Leseoperation fest. Der OP fragte nach Leerlauf-Timeout. –

8

Sie kann nicht eine Leerlaufverbindung Timeout in der Config für Apache HTTP Client festlegen. Der Grund ist, dass dabei ein Leistungsaufwand entsteht.

Die Dokumentation zeigt deutlich, warum, und gibt ein Beispiel für eine inaktive Verbindungsmonitorimplementierung, die Sie kopieren können. Im Wesentlichen ist dies ein weiterer Thread, den Sie regelmäßig ausführen closeIdleConnections rufen HttpClientConnectionManager

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html

Einer der wichtigsten Mängel der klassischen Blockierung I/O-Modell ist, dass der Netzwerkbuchse an E/A-Ereignisse reagieren kann nur wenn es in einer E/A-Operation blockiert ist. Wenn eine Verbindung wieder zum Manager freigegeben wird, kann sie am Leben erhalten werden, jedoch kann sie den Status des Sockets nicht überwachen und auf keine E/A-Ereignisse reagieren. Wenn die Verbindung auf der Serverseite geschlossen wird, kann die clientseitige Verbindung die Änderung des Verbindungsstatus nicht erkennen (und entsprechend reagieren, indem sie den Socket an seinem Ende schließt). HttpClient versucht, das Problem zu mildern, indem getestet wird, ob die Verbindung "veraltet" ist, die nicht mehr gültig ist, da sie auf der Serverseite geschlossen wurde, bevor die Verbindung zur Ausführung einer HTTP-Anforderung verwendet wurde. Die veraltete Verbindungsprüfung ist nicht 100% zuverlässig und fügt jeder Anforderungsausführung 10 bis 30 ms Overhead hinzu. Die einzige praktikable Lösung, die kein Modell mit einem Thread pro Socket für inaktive Verbindungen erfordert, ist ein dedizierter Monitor-Thread, mit dem Verbindungen gelöscht werden, die aufgrund einer langen Inaktivitätsperiode als abgelaufen gelten. Der Monitor-Thread kann regelmäßig die Methode ClientConnectionManager # closeExpiredConnections() aufrufen, um alle abgelaufenen Verbindungen zu schließen und geschlossene Verbindungen aus dem Pool zu entfernen. Optional können Sie auch die Methode #ClientConnectionManager # closeIdleConnections() aufrufen, um alle Verbindungen zu schließen, die über einen bestimmten Zeitraum inaktiv waren.