Les meilleures Pratiques à Utiliser HttpClient en Environnement Multithread

Pendant un certain temps, j'ai été en utilisant HttpClient dans un environnement multithread. Pour chaque thread, lorsqu'il établit une connexion, il va créer un tout nouveau HttpClient instance.

Récemment, j'ai découvert que, en utilisant cette approche, il peut causer à l'utilisateur d'avoir un trop grand nombre de ports qui sont ouverts et la plupart des connexions sont en état TIME_WAIT.

http://www.opensubscriber.com/message/[email protected]/86045.html

Ainsi, au lieu de chaque thread en train de faire :

HttpClient c = new HttpClient();
try {
    c.executeMethod(method);
}
catch(...) {
}
finally {
    method.releaseConnection();
}

Nous avons prévu :

MÉTHODE[A]

//global_c is initialized once through
//HttpClient global_c = new HttpClient(new MultiThreadedHttpConnectionManager());

try {
    global_c.executeMethod(method);
}
catch(...) {
}
finally {
    method.releaseConnection();
}

Dans une situation normale, global_c sera accessible par 50++ threads simultanément. Je me demandais, ça va créer des problèmes de performances? Est MultiThreadedHttpConnectionManager à l'aide d'un lock-free mécanisme de mise en œuvre de son thread-safe de la politique?

Si 10 threads à l'aide de global_c, les autres 40 threads être verrouillé?

Ou serait-ce mieux si, dans chaque thread, j'ai créer une instance d'un HttpClient, mais relâchez le gestionnaire de connexion de façon explicite?

MÉTHODE[B]

MultiThreadedHttpConnectionManager connman = new MultiThreadedHttpConnectionManager();
HttpClient c = new HttpClient(connman);
try {
      c.executeMethod(method);
}
catch(...) {
}
finally {
    method.releaseConnection();
    connman.shutdown();
}

Sera connman.shutdown() souffrent de problèmes de performance?

Pourrais-je savoir quelle méthode (A ou B) est préférable, pour des applications à l'aide d'un 50++ fils?

InformationsquelleAutor Cheok Yan Cheng | 2009-08-15
  1. 43

    Certainement Une Méthode parce que ses mises en commun et thread-safe.

    Si vous utilisez httpclient 4.x, le gestionnaire de connexion est appelé ThreadSafeClientConnManager. Voir ce lien pour plus de détails (faites défiler jusqu'à "la Mutualisation du gestionnaire de connexion"). Par exemple:

        HttpParams params = new BasicHttpParams();
    SchemeRegistry registry = new SchemeRegistry();
    registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
    ClientConnectionManager cm = new ThreadSafeClientConnManager(params, registry);
    HttpClient client = new DefaultHttpClient(cm, params);
    • ThreadSafeClientConnManager a été dépréciée en faveur de PoolingClientConnManager en 4.2
    • Salut, peut-httpclient créée par cette méthode sert à maintenir la session, comme décrit ici stackoverflow.com/questions/5960832/... ...? Parce que quand j'ai essayé, je n'étais pas en mesure de maintenir la session à travers les différentes demandes ...
    • 4.3.1 ici: PoolingClientConnManager a été dépréciée en faveur de PoolingHttpClientConnectionManager.
    • Nouveau PoolingClientConnManager était deprecatd en faveur de PoolingHttpClientConnectionManager
    InformationsquelleAutor
  2. 17

    Méthode est recommandée par httpclient de la communauté des développeurs.

    Veuillez vous référer http://www.mail-archive.com/[email protected]/msg02455.html pour plus de détails.

    • Quand un appel "shutdown" sur le gestionnaire de connexion si le client est globaux.
    • Quels sont les outils / commandes linux sont utiles pour déboguer ou "visualiser" le comportement de la ConnectionManager sous le capot? Je demande parce que nous avons actuellement des problèmes avec les connexions dans CLOSE_WAIT et d'autres effets, et nous sommes strugeling trouver un bon moyen de voir ce qui se passe exactement sur.
    • je suis assez sûr que vous suffit d'appeler de l'arrêt lorsque le programme se termine ou lorsque vous avez terminé avec quelques lots de travail où vous n'aurez pas besoin de connexions depuis un certain temps.
    • fait un très beau travail. technet.microsoft.com/en-us/sysinternals/bb897437.aspx trop
    InformationsquelleAutor Cheok Yan Cheng
  3. 13

    Ma lecture de la doc, c'est que HttpConnection lui-même n'est pas considéré comme thread-safe, et donc MultiThreadedHttpConnectionManager fournit une réutilisables piscine de HttpConnections, vous avez un seul MultiThreadedHttpConnectionManager partagée par tous les threads et initialisé exactement une fois. Si vous avez besoin d'un couple de petites améliorations de l'option A.

    MultiThreadedHttpConnectionManager connman = new MultiThreadedHttpConnectionManag

    Ensuite, chaque thread doit être à l'aide de la séquence pour chaque demande, obtenir une connexion à partir de la piscine et de le remettre à l'achèvement de ses travaux - à l'aide d'un bloc finally peut être bon.
    Vous devez également code de la possibilité que la piscine n'a pas de connexions disponibles et le processus de l'exception délai.

    HttpConnection connection = null
try {
    connection = connman.getConnectionWithTimeout(
                        HostConfiguration hostConfiguration, long timeout) 
    //work
} catch (/*etc*/) {/*etc*/} finally{
    if ( connection != null )
        connman.releaseConnection(connection);
}

    Que vous êtes en utilisant un pool de connexions, vous n'allez pas fermer les connexions et donc cela ne devrait pas frapper le TIME_WAIT problème. Cette approche ne assuume que chaque thread n'a pas de s'accrocher à la connexion pour longtemps. Notez que l'escroc lui-même est laissé ouvert.

    • N'ai pas la réponse à ma question, sur la méthode (A ou B), c'est mieux.
    • La réponse a été qu'elle n'est pas correcte. Je vais le préciser.
    InformationsquelleAutor djna
  4. 5

    Je pense que vous voulez utiliser ThreadSafeClientConnManager.

    Vous pouvez voir comment cela fonctionne ici: http://foo.jasonhudgins.com/2009/08/http-connection-reuse-in-android.html

    Ou dans le AndroidHttpClient qui l'utilise en interne.

    • Opps. Pas de plan à migrer à partir de HttpClient 3.x à 4.x, 3.x avait été en cours d'exécution sans faille dans mon application depuis près de ~2 ans 🙂
    • Bien sûr, si quelqu'un d'autre est venu ici à Googler pour la réponse 🙂
    InformationsquelleAutor Thomas Ahle
  5. 2

    Avec HttpClient 4.5 vous pouvez faire ceci:

    CloseableHttpClient httpClient = HttpClients.custom().setConnectionManager(new PoolingHttpClientConnectionManager()).build();

    Remarque que celui-ci met en œuvre Fermer (pour arrêter le gestionnaire de connexion).

    InformationsquelleAutor Dimitar II