Ne HttpClient et HttpClientHandler doivent être éliminés?

Système.Net.Http.HttpClient et Système.Net.Http.HttpClientHandler dans .NET Framework 4.5 mettre en œuvre IDisposable (via Système.Net.Http.HttpMessageInvoker).

La using déclaration de documentation dit:

En règle générale, lorsque vous utilisez un IDisposable objet, vous devez déclarer et
l'instancier dans une instruction d'utilisation.

Cette réponse utilise ce modèle:

var baseAddress = new Uri("http://example.com");
var cookieContainer = new CookieContainer();
using (var handler = new HttpClientHandler() { CookieContainer = cookieContainer })
using (var client = new HttpClient(handler) { BaseAddress = baseAddress })
{
    var content = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("foo", "bar"),
        new KeyValuePair<string, string>("baz", "bazinga"),
    });
    cookieContainer.Add(baseAddress, new Cookie("CookieName", "cookie_value"));
    var result = client.PostAsync("/test", content).Result;
    result.EnsureSuccessStatusCode();
}

Mais les exemples les plus connus de Microsoft n'appelez pas Dispose() que ce soit explicitement ou implicitement. Par exemple:

Dans le annonceles commentaires, quelqu'un a demandé à l'employé de Microsoft:

Après vérification de vos échantillons, j'ai vu que vous n'avez pas réussi à l'éliminer
action sur HttpClient instance. J'ai utilisé toutes les instances de HttpClient
avec l'aide de déclaration sur mon application et j'ai pensé que c'est la bonne façon
depuis HttpClient implémente l'interface IDisposable. Suis-je sur la
droit chemin?

Sa réponse a été:

En général c'est correct, bien que vous devez être prudent avec les
"à l'aide de" et asynchrone comme ils ne sont pas vraiment mélanger .Net 4, Dans .Net 4.5 vous
pouvez utiliser "en attente" à l'intérieur d'une "aide" de la déclaration.

Btw, vous pouvez réutiliser la même HttpClient autant de fois sont [comme] vous aimez, de sorte
en général, vous n'aurez pas créer/débarrasser d'eux tout le temps.

Le deuxième paragraphe est inutile à cette question, qui n'est pas préoccupé par la façon dont beaucoup de temps vous pouvez utiliser un HttpClient exemple, mais si il est nécessaire de se débarrasser une fois que vous n'en avez plus besoin.

(Mise à jour: en fait, c', deuxième alinéa, est la clé de la réponse, comme prévu ci-dessous par @DPeden.)

Donc mes questions sont:

  1. Est-il nécessaire, étant donné le contexte actuel de mise en œuvre (.NET Framework 4.5), pour appeler dispose() sur HttpClient et HttpClientHandler instances? Précision: par "nécessaire", je veux dire s'il y a des conséquences négatives pour ne pas disposer des ressources, par exemple les fuites de données ou les risques de corruption.

  2. Si il n'est pas nécessaire, serait-ce une "bonne pratique" de toute façon, puisqu'ils mettent en œuvre IDisposable?

  3. Si c'est nécessaire (ou recommandé), est ce code mentionné ci-dessus de la mettre en œuvre en toute sécurité (par .NET Framework 4.5)?

  4. Si ces classes ne nécessitent pas d'appeler dispose(), pourquoi ont-ils été mis en œuvre comme IDisposable?

  5. Si ils ont besoin, ou si c'est une pratique recommandée, Microsoft exemples trompeuse ou dangereux?

  • "Si elle n'est pas absolument nécessaire..." - il n'est jamais "absolument nécessaire" pour disposer de tout Jetable. De la même manière qu'il n'est pas "absolument nécessaire" pour vous débarrasser de vos déchets de façon responsable si vous êtes en visite à la maison d'autrui.
  • merci pour vos commentaires. Avez-vous des suggestions sur comment je pourrais préciser la question? Je veux savoir si elle peut conduire à des problèmes généralement associés à ne pas disposer de ressources, tels que la fuite de ressources et la corruption des données.
  • Pas vrai. En particulier, les flux les écrivains doivent être disposées à avoir des comportement correct.
  • Je suppose que je ne vois pas le point de l'ensemble de la question. Vous êtes au courant qu'ils mettent en œuvre le modèle jetable. Vous êtes conscient de ce que vous (en tant que bon citoyen/consommateur) sont destinés à faire avec un objet jetable lorsque vous n'en avez plus besoin. Vous êtes également conscient que l'attente est que l'un de ces objets peut être utilisé pour de multiples demandes, de sorte que vous êtes peu probable de voir des exemples que tout simplement en créer un, d'envoyer une seule demande, et puis immédiatement se débarrasser de lui.
  • quels sont les aspects que vous envisagez de vous? Certainement, vous pouvez appeler Flush sur un après chaque écriture, et d'autres que les inconvénients de celle-ci en continuant à maintenir les ressources sous-jacentes pour plus longtemps que nécessaire, ce qui ne se produira pas qui est nécessaire pour "comportement correct"?
  • dans le code que j'ai l'habitude d'écrire, j'ai créer un nouveau HttpClient exemple quand j'ai besoin d'envoyer une nouvelle demande au lieu de garder ce client exemple autour. Je pense qu'il se trouve bien avec les apatrides de la nature du protocole HTTP. Mais je n'ai habituellement pas de disposer de ces instances, et aujourd'hui seulement, j'ai remarqué qu'ils mettent en œuvre IDisposable. C'est pourquoi j'essaie de savoir si je suis attendu à les disposer de manière explicite. J'espère que précise ma question.
  • Il ne semble pas être une évidence de réponse claire à cette question. Considérant qu'il doit être l'un des plus utilisés .net classes dans l'internet moderne du monde, je trouve ça assez étrange que MSDN n'a pas clairement précisé comment il doit être utilisé.
  • C'est simplement faux: "en règle générale, lorsque vous utilisez un IDisposable objet, vous devez déclarer et instancier dans une instruction d'utilisation". Je voudrais lire la documentation de la classe de mise en œuvre IDisposable toujours avant de décider si je dois utiliser une aide pour elle. Comme l'auteur de bibliothèques où je mettre en œuvre IDisposable parce que le besoin de libérer unmanged ressources, je serais horrifié si les consommateurs créé disposé d'une instance à chaque fois, au lieu de ré-utiliser une instance existante. Cela ne veut pas dire ne pas jeter de l'instance finalement..
  • J'ai soumis un PR de microsoft pour mettre à jour leurs docs: github.com/dotnet/docs/pull/2470
  • Le jetable modèle est nécessaire à l'apprentissage du C# .net 4.5 certification. La confusion réside dans la compatibilité avec des .net 2.0-utilisation de idisposible (comme avec la mémoire des ruisseaux et des IEnumerable). Vous devez veiller à disposer est appelée immédiatement après avoir terminé de l'utiliser pour tout ce qui encapsule “ ressources externes”. Fichier sont un bon exemple. Lorsqu'un client http (par question) lit un fichier, même si vous exécutez chasse d'eau, une longue verrou est maintenu. Sur votre système de GC nettoyer rapidement. Sur un autre, qui sait. Ou en tant que vos changements de l'environnement. Mo un jour, il ne peut pas être écrit.

InformationsquelleAutor Fernando Correia | 2013-03-29
  1. 227

    Le consensus général est que vous n'avez pas (ne doit pas) la nécessité de disposer de HttpClient.

    Beaucoup de gens qui sont intimement impliqués dans la façon de travailler ont déclaré cette.

    Voir Darrel Miller post de blog et une SORTE de poste: HttpClient ramper résultats de fuite de mémoire de référence.

    Je voudrais aussi vous suggère fortement de lire le HttpClient chapitre de la Conception de Évolutives Api Web avec ASP.NET pour le contexte de ce qui se passe sous le capot, en particulier le "Cycle de vie" article cité ici:

    Bien que HttpClient fait indirectement mettre en œuvre la IDisposable
    l'interface, l'utilisation standard de HttpClient est de ne pas les jeter
    après chaque demande. L'objet HttpClient est destiné à vivre pour que
    longtemps que votre application a besoin de faire des requêtes HTTP. Ayant un objet
    exister à travers des demandes multiples permet à un endroit de mise en
    DefaultRequestHeaders et vous évite d'avoir à re-préciser
    des choses comme CredentialCache et CookieContainer sur chaque demande
    a été nécessaire avec HttpWebRequest.

    Ou même ouvrir DotPeek.

    • Pour préciser votre réponse, serait-il correct de dire que "vous n'avez pas besoin de disposer de HttpClient SI VOUS TENEZ À L'INSTANCE afin de le RÉUTILISER plus TARD"? Par exemple, si une méthode est appelée à plusieurs reprises et crée un nouveau HttpClient exemple (même si ce n'est pas le modèle recommandé dans la plupart des cas), encore faudrait-il correct de dire que cette méthode ne doit pas disposer de l'instance (qui ne seront pas réutilisés)? Cela pourrait conduire à des milliers de undisposed instances. En d'autres termes, que vous devriez essayer et de réutiliser les instances, mais si vous ne les réutilisez pas, vous feriez mieux de se débarrasser d'eux (pour libérer les connexions)?
    • Je pense que l'naturellement frustrant mais la bonne réponse est: cela dépend. Si je devais être épinglé à donner des conseils d'ordre général qui a travaillé dans la plupart (je n'ai jamais dire tous) des cas, je vous suggère d'utiliser un conteneur IoC et l'inscription d'une instance de HttpClient comme un singleton. La durée de vie de l'instance sera ensuite étendue à celle de la durée de vie du conteneur. Cela pourrait être étendue au niveau de l'application ou peut-être par requête dans une application web.
    • Mes plats à emporter, c'est que votre réponse est que l'a recommandé le mode d'utilisation est à éviter à plusieurs reprises la création et à l'élimination HttpClient cas, mais de réutiliser la même instance tout au long du cycle de vie d'application. Donc vous ne serez jamais "fait" avec le HttpClient instance jusqu'à ce que l'application se termine. Suivant ce modèle, vous aurez rarement à atteindre un point où vous êtes "fait" à l'aide de l'instance, jusqu'à ce que l'application se termine.
    • Oui. Si pour quelque raison vous n'avez à plusieurs reprises de créer et de détruire HttpClient cas, alors oui, vous devriez Jeter. Je ne suggère pas d'ignorer l'interface IDisposable, juste essayer d'encourager les gens à utiliser de nouveau cas.
    • Juste pour ajouter plus de crédibilité à cette réponse, j'ai parlé avec le HttpClient l'équipe d'aujourd'hui et ils ont confirmé que HttpClient n'a pas été conçu pour être utilisé par demande. Une instance de HttpClient doit être gardé en vie, tandis qu'une application client continue à interagir avec un hôte particulier.
    • L'enregistrement HttpClient comme un singleton sons dangereux pour moi parce que c'est mutable. Par exemple, ne serait pas tout le monde de l'affectation à la Timeout bien être en piétinant les uns les autres?
    • Il faut également noter qu'une seule instance de la HttpClient ne respecte pas les modifications de DNS. Voir byterot.blogspot.se/2016/07/singleton-httpclient-dns.html pour plus de détails (Et de github.com/dotnet/corefx/issues/11224 pour le problème de DNS dans dotnetcore)
    • Et pour ajouter aux problèmes mis en évidence par @Jon-Eric et @GreenMoose, des choses comme les certificats de client et de serveur personnalisé de validation de certificat de rappel font partie de HttpClients'etat (par le biais de son HttpMessageHandler paramètre du constructeur).

    InformationsquelleAutor David Peden
  2. 38

    L'actuel réponses sont un peu à confusion et induire en erreur, et qu'ils manquent d'importantes DNS implications. Je vais essayer de résumer où en sont les choses clairement.

    1. Manière générale, la majorité IDisposable objets devrait idéalement être éliminés lorsque vous avez terminé avec eux, en particulier ceux qui propre Nom/système d'exploitation partagée des ressources. HttpClient n'est pas une exception, puisque, comme Darrel Miller souligne qu'il alloue des jetons d'annulation et demande de réponse des organismes non gérés en flux.
    2. Cependant, la les meilleures pratiques pour HttpClient dit que vous devez créer une instance de réutiliser autant que possible (à l'aide de son thread-safe membres en multi-thread scénarios). Par conséquent, dans la plupart des scénarios vous ne serez jamais en disposer tout simplement parce que vous aurez besoin de tout le temps.
    3. Le problème avec les ré-utiliser les mêmes HttpClient "pour toujours", c'est que le sous-jacent HTTP connexion peut rester ouverte à l'encontre de l'origine DNS-IP résolue, indépendamment des modifications de DNS. Cela peut être un problème dans de tels scénarios bleu/vert de déploiement et DNS de basculement. Il existe différentes approches pour traiter ce problème, le plus fiable impliquant le serveur d'envoi d'un Connection:close la tête à la suite des modifications DNS lieu. Une autre possibilité consiste à recycler le HttpClient sur le côté client, soit périodiquement, soit via un mécanisme qui détecte le changement de DNS. Voir https://github.com/dotnet/corefx/issues/11224 pour plus d'informations (je suggère de le lire attentivement avant l'aveuglette, en utilisant le code proposé dans le lié billet de blog).
    • Je dispose de tout le temps que je ne peux pas changer le proxy sur un exemple 😉
    • Si vous avez besoin de disposer de HttpClient pour quelque raison que ce soit, vous devez garder une instance statique de la HttpMessageHandler autour de, la disposition que l'on est réellement la cause des problèmes attribuables à la disposition de la HttpClient. HttpClient a une surcharge du constructeur qui vous permet de spécifier la fourni gestionnaire ne doit pas être jeté, dans ce cas, vous pouvez réutiliser le HttpMessageHandler avec d'autres HttpClient instances.
    • Vous devez tenir vos HttpClient, mais vous pouvez utiliser quelque chose comme Système.Net.ServicePointManager.DnsRefreshTimeout = 3000; C'est utile par exemple si vous êtes sur un appareil mobile qui à tout moment peut basculer entre le wifi et la 4G.
    InformationsquelleAutor Ohad Schneider
  3. 16

    Dans ma compréhension, l'appel de Dispose() est nécessaire uniquement en cas de verrouillage de ressources dont vous avez besoin plus tard (comme une connexion particulière). C'est toujours recommandé de libérer des ressources que vous n'utilisez plus, même si vous n'avez pas besoin de nouveau, tout simplement parce que vous ne devriez pas généralement s'accrocher à des ressources que vous ne l'utilisez pas (pun intended).

    L'exemple de Microsoft n'est pas faux, forcément. Toutes les ressources utilisées sera libérée lorsque l'application se ferme. Et dans le cas de cet exemple, ce qui arrive presque immédiatement après l' HttpClient est en fait utilisé. Dans pareil cas, l'appelant explicitement Dispose() est un peu superflue.

    Mais, en général, lorsqu'une classe implémente IDisposable, de la compréhension, c'est que vous Dispose() de ses instances dès que vous êtes prêt et capable. J'avais poser la c'est particulièrement vrai dans des cas comme HttpClient où il n'est pas explicitement documentées quant à savoir si les ressources ou les connexions sont détenus sur/ouvrir. Dans le cas où la connexion sera réutilisé à nouveau [bientôt], vous aurez envie de renoncer à Dipose()ing de l'il -- vous n'êtes pas "prêt" dans ce cas.

    Voir aussi:
    IDisposable.Méthode Dispose et Quand faire appel à Disposer

    • C'est comme si quelqu'un met une banane dans votre maison, il mange, et il est debout leur avec la peau. Que doivent-ils faire avec la peau? ... Si ils sont sur leur chemin hors de la porte avec elle, laissez-les aller. Si ils sont rester dans les parages, les faire jeter à la poubelle afin de ne pue pas la place.
    • juste pour clarifier cette réponse, dites-vous, "il n'est pas nécessaire de disposer si le programme est en fin de droit après que vous l'utilisez"? Et que vous devriez jeter si le programme devrait se poursuivre pendant un certain temps à faire d'autres choses?
    • Oui, sauf si j'oublie quelque chose, je pense que c'est un coffre-fort principe. Donnez-lui quelque pensée, dans chaque cas, cependant. Si vous travaillez avec une connexion, par exemple, vous ne voulez pas Dispose() de ce prématurément et reconnectez quelques secondes plus tard si la connexion existante est réutilisable. De même, vous ne voulez pas inutilement Dispose() d'images ou d'autres structures, vous pourriez vous retrouver avoir à reconstruire dans une minute ou deux.
    • Je comprends. Mais dans le cas particulier de HttpClient et HttpClientHandler qui cette question est à propos, ils organisent une ressource ouverte comme une connexion HTTP? Si c'est ce qui se passe, je pourrais avoir à repenser ma façon de les utiliser.
    • Voir mon edit, par la manière. J'ai ajouté deux ressources que vous pouvez comparer ma réponse. Ils donnent un peu plus de nuance; mais je pense que mes règle générale satisfait aux recommandations.
    • Sans le tester pour voir si la connexion reste ouverte (ou si le KeepAlive en-tête est envoyée), l'ambiguïté serait de m'inviter à la faveur Dipose()ing du client lorsqu'il n'est plus nécessaire. Et, par ma règle générale, c'est en quelque sorte ma préférence, même sans l'ambiguïté. Et je pense que c'est généralement ce que la mise en œuvre de IDisposable suggère: Appel Dispose() sur moi dès que vous êtes prêt à vous!
    • Bonne référence pour la blog. Même Microsoft experts conviennent que la question est source de confusion. Je vais supposer HttpClient tombe dans la catégorie 1 (nom/système d'exploitation partagée des ressources) de l'orientation est "si vous le possédez, mettez-la au Rebut".
    • Cette réponse n'est pas HttpClient spécifique et est incorrect à l'égard de la demande sur le comportement documenté. Voir ma réponse ci-dessous.
    • Votre réponse n'est pas du tout en conflit avec la mienne. Remarque, je l'ai dit, vous devriez Dispose() de ses instances dès que vous avez entièrement prêt et en mesure. Si vous prévoyez sur l'utilisation de l'instance de nouveau, vous n'êtes pas prêt.
    • D'accord. Donc je n'ai pas vote " il.
    • Ma compréhension est que techniquement c'est correct que vous devriez jeter le HttpClient instance après que vous avez terminé de l'utiliser. Mais @DPeden fait un bon point, pris en charge par des explications, que le modèle recommandé est de conserver la réutilisation de la même instance. En ce sens, vous ne serez jamais "fait" avec elle, afin de ne pas arriver à un point où l'élimination de celui-ci devient un sujet de préoccupation. La création et l'élimination de HttpClient cas, à plusieurs reprises, sans doute, un anti-modèle.
    • Sachez que l'appelant dispose sur HttpClientHandler de force à la ferme une Connexion HTTP est dans le pool de connexion. C'est même si le serveur renvoie une Connexion: keep-alive-tête. La seule utilisation que j'ai trouvé pour ce problème est sur un appareil mobile, il peut y avoir certains scénarios où vous pourriez économiser de l'énergie.
    • Comme je l'ai dit à plusieurs reprises, il est absurde de disposer de aucun ressources vous prévoyez sur l'utilisation de nouveau [bientôt]. Mais, si vous êtes à la pas de planification sur l'utilisation de la connexion de nouveau [bientôt], c'est une mauvaise pratique de le laisser traîner. C'est un abus de ressources. Les règles pour une Connexion HTTP ne diffèrent pas, en général, de ceux de toute autre connexion ou de ressources.
    • Vous semblez avoir l'impression que je suis en plaidant en faveur de l'appel de Dispose() dans tous les cas, ce que je ne suis pas. Je ne suis pas sûr de savoir comment je peux être plus clair. C'est une bonne pratique pour Dipose()/ressources gratuites que vous n'avez pas besoin. Si vous besoin ces ressources, manifestement, vous ne devriez pas être Dispose()ing d'entre eux!
    • Par définition, une "mise en commun des ressources" prendre la responsabilité de la gestion de durée de vie de la main de l'application. Il est de la responsabilité de ServicePointManager de décider quand la connexion TCP sera fermé, pas votre application. C'est la même chose pour des connexions de base de données. La fermeture d'une connexion DB (qui est mis en commun) ne le fait pas de la fermer.
    • La sémantique. Si votre application ou le fil est maintenant sur une ressource d'une autre application peut être en mesure d'utiliser, c'est votre application de la responsabilité pour libérer la ressource lorsqu'il n'est plus nécessaire. Si cela implique la fermeture de la connexion ou tout simplement de le libérer pour une utilisation par un autre processus n'est pas pertinent pour le point.
    • Je suis entièrement d'accord si la méthode dispose de HttpClientHandler ne pas aller chercher dans ServicePointManager pour un pool de connexion associé à la dernière RequestURI et le fermer. Je n'ai aucune idée de pourquoi ils ont mis cette.
    • Probablement parce qu'ils ont compris il y a peu de chance qu'un autre processus est en utilisant la même connexion ou qui ont besoin de la même cookies (je suppose qu'il détient sur les cookies). Donc, en plus d'être un risque de sécurité potentiel pour partager la connexion avec d'autres processus, c'est le "manque de considération" pour sortir de la connexion autour de la pose que personne n'a besoin. Ce n'est pas comme une application web de connexion de base de données, par exemple, où tout peut utiliser la même connexion. C'est un client web. Les Chances sont, votre processus a besoin de quelque chose qui n'est pas pertinente à d'autres processus.

    InformationsquelleAutor svidgen
  4. 8

    Dispose() appelle le code ci-dessous, qui ferme les connexions ouvertes par la HttpClient instance. Le code a été créé par la décompilation avec dotPeek.

    HttpClientHandler.cs - Disposer

    ServicePointManager.CloseConnectionGroups(this.connectionGroupName);

    Si vous n'appelez pas disposer ensuite ServicePointManager.MaxServicePointIdleTime, qui s'exécute par une minuterie, va fermer les connexions http. La valeur par défaut est de 100 secondes.

    ServicePointManager.cs

    internal static readonly TimerThread.Callback s_IdleServicePointTimeoutDelegate = new TimerThread.Callback(ServicePointManager.IdleServicePointTimeoutCallback);
private static volatile TimerThread.Queue s_ServicePointIdlingQueue = TimerThread.GetOrCreateQueue(100000);

private static void IdleServicePointTimeoutCallback(TimerThread.Timer timer, int timeNoticed, object context)
{
  ServicePoint servicePoint = (ServicePoint) context;
  if (Logging.On)
    Logging.PrintInfo(Logging.Web, SR.GetString("net_log_closed_idle", (object) "ServicePoint", (object) servicePoint.GetHashCode()));
  lock (ServicePointManager.s_ServicePointTable)
    ServicePointManager.s_ServicePointTable.Remove((object) servicePoint.LookupString);
  servicePoint.ReleaseAllConnectionGroups();
}

    Si vous n'avez pas de définir la durée d'inactivité à l'infini alors il semble sûr de ne pas appeler de céder et de laisser la connexion inactive minuterie coup de pied dans et fermer les connexions pour vous, bien que ce serait mieux pour vous d'appeler l'éliminer à l'aide d'instruction si vous savez que vous êtes fait avec un HttpClient exemple et de libérer les ressources plus rapidement.

    InformationsquelleAutor Timothy Gonzalez
  5. 5

    Dans mon cas, j'ai été la création d'un HttpClient à l'intérieur d'une méthode qui a fait l'appel de service. Quelque chose comme: 

    public void DoServiceCall() {
  var client = new HttpClient();
  await client.PostAsync();
}

    Dans l'Azur rôle de travailleur, après avoir à plusieurs reprises à l'appel de cette méthode (sans disposer de la HttpClient), il finit par échouer avec SocketException (tentative de connexion a échoué).

    J'ai fait le HttpClient une variable d'instance (le disposer au niveau de la classe) et le problème a disparu. Donc je dirais que, oui, disposer les HttpClient, en supposant que son coffre-fort (vous n'avez pas de circulation d'appels asynchrones) de le faire.

    • Merci pour les commentaires. C'est un peu complexe. Je vous recommande de lire les articles dans DPeden de réponse. En bref, le HttpClient instance doit être réutilisés tout au long du cycle de vie des applications. Si vous décidez de créer de nouvelles instances à plusieurs reprises, vous pourriez avoir besoin d'en disposer.
    • "la HttpClient instance doit être réutilisés tout au long du cycle de vie des applications" - ce juste n'est pas une bonne idée avec un grand nombre d'applications. Je pense à des applications web qui utilisent HttpClient. HttpClient est titulaire d'état (par exemple les en-têtes de requête, il va utiliser), donc une requête web thread pourrait facilement piétiner ce que fait l'autre. Dans les grandes applications web j'ai vu aussi des HttpClient que le problème des grands problèmes de connexion. Dans le doute, je le dis d'en Disposer.
    • vous ne pouvez pas effacer les en-têtes et d'en ajouter de nouvelles avant chaque requête?
    • Microsoft recommande également de réutiliser HttpClient cas - docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/...
    • cet exemple semble être un client comme une application console. Je faisais allusion à une application web étant le client.
    • Salut @nashwan, veuillez trouver un lien correct pour les applications web ici - msdn.microsoft.com/en-us/library/...

    InformationsquelleAutor David Faivre
  6. 4

    Réponse courte: Non, l'instruction dans la actuellement accepté la réponse n'est PAS exacte: "Le consensus général est que vous n'avez pas (ne doit pas) la nécessité de disposer de HttpClient".

    Réponse longue: les DEUX déclarations suivantes sont vraies et achieveable en même temps:

    1. "HttpClient est conçu pour être instancié une fois et ré-utilisé tout au long de la durée de vie d'une application", cité de la documentation officielle.
    2. Un IDisposable objet est censé/recommandé pour être éliminés.

    Et ils NE sont PAS NÉCESSAIREMENT en CONFLIT les uns avec les autres. C'est juste une question de comment vous organisez votre code à réutiliser un HttpClient ET toujours en disposer correctement.

    Un même réponds plus cité de mon une autre réponse:

    Il n'est pas un hasard de voir des gens
    dans certains articles de blog blâmer comment HttpClient 's IDisposable interface
    les fait ont tendance à utiliser le using (var client = new HttpClient()) {...} modèle
    et puis conduire à épuisement socket gestionnaire de problème.

    Je crois que c'est un non-dits (sig?)conception:
    "un IDisposable objet devrait être de courte durée".

    TOUTEFOIS, bien qu'il ressemble certainement une courte durée chose quand nous écrire du code dans ce style:

    using (var foo = new SomeDisposableObject())
{
    ...
}

    la la documentation officielle sur IDisposable
    ne mentionne jamais IDisposable objets doivent être de courte durée.
    Par définition, IDisposable est simplement un mécanisme pour vous permettre de vous libérer des ressources non managées.
    Rien de plus. En ce sens, vous êtes ATTENDUS pour éventuellement déclencher la disposition,
    mais il ne vous oblige pas à le faire dans une courte durée de la mode.

    Il est donc de votre travail pour bien choisir quand déclencher l'élimination,
    la base de votre objet réel du cycle de vie de l'obligation.
    Il n'y a rien qui vous empêche d'utiliser un IDisposable dans une longue durée de vie moyen:

    using System;
namespace HelloWorld
{
    class Hello
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");

            using (var client = new HttpClient())
            {
                for (...) { ... }  //A really long loop

                //Or you may even somehow start a daemon here

            }

            //Keep the console window open in debug mode.
            Console.WriteLine("Press any key to exit.");
            Console.ReadKey();
        }
    }
}

    Avec cette nouvelle compréhension, maintenant nous revoir ce billet de blog,
    nous pouvons clairement remarquer que la "solution" initialise HttpClient une fois, mais jamais en disposer,
    c'est pourquoi nous pouvons voir à partir de son netstat sortie,
    la connexion reste à l'état ce qui signifie qu'il n'a PAS été correctement fermé.
    Si c'était fermé, son état serait en TIME_WAIT à la place.
    Dans la pratique, il n'est pas une grosse affaire de la fuite d'une connexion ouverte après l'ensemble de votre programme se termine,
    et le blog affiche encore un gain de performance après le correctif;
    mais encore, il est conceptuellement erroné de blâmer IDisposable et choisissez de ne PAS la jeter.

    • merci pour cette explication. Il est clairement jeter un peu de lumière vers le consensus. De votre avis, si vous pensez que c'est bon pour appeler HttpClient.Dispose ?.
    • mettez-la au rebut lorsque votre application n'a plus besoin d'utiliser le httpClient instance. Vous pourriez penser une telle suggestion sons de vagues, mais en fait, il peut parfaitement en harmonie avec le cycle de vie de votre HttpClient client variable, qui est une Programmation-101 chose que vous êtes sans doute déjà faire de toute façon. Vous pourriez même être capable de les utiliser using (...) {...} trop. Par exemple, voir l'exemple Hello World à l'intérieur de ma réponse.
    InformationsquelleAutor RayLuo
  7. 3

    En utilisation typique (réponses<2 GO) il n'est pas nécessaire de Disposer de HttpResponseMessages.

    Les types de retour de la HttpClient méthodes doivent être Éliminés si leur Flux de Contenu n'est pas entièrement Lu. Sinon il n'y a aucun moyen pour le CLR, à savoir ceux des cours d'eau peut être fermé jusqu'à ce qu'ils sont des ordures.

    • Si vous êtes à la lecture de données dans un byte[] (par exemple, GetByteArrayAsync) ou de la chaîne, toutes les données sont lues, donc il n'est pas nécessaire d'en disposer.
    • Les autres surcharges par défaut pour la lecture du Flux jusqu'à 2 go (HttpCompletionOption est ResponseContentRead, HttpClient.MaxResponseContentBufferSize par défaut est de 2 go)

    Si vous définissez la HttpCompletionOption à ResponseHeadersRead ou la réponse est supérieure à 2 GO, vous devriez nettoyer. Cela peut être fait en appelant dispose sur le HttpResponseMessage ou en appelant Jeter/Fermer sur le cours d'eau obtenu à partir de la HttpResonseMessage Contenu ou par la lecture du contenu complètement.

    Si vous appelez dispose sur le HttpClient dépend si vous souhaitez annuler les demandes en attente ou pas.

    InformationsquelleAutor Tom Deseyn
  8. 2

    Si vous souhaitez vous débarrasser de HttpClient, vous pouvez si vous le mettez en place un centre de ressources. Et à la fin de votre demande, vous jetez votre pool de ressources.

    Code:

    //Notice that IDisposable is not implemented here!
public interface HttpClientHandle
{
HttpRequestHeaders DefaultRequestHeaders { get; }
Uri BaseAddress { get; set; }
//...
//All the other methods from peeking at HttpClient
}
public class HttpClientHander : HttpClient, HttpClientHandle, IDisposable
{
public static ConditionalWeakTable<Uri, HttpClientHander> _httpClientsPool;
public static HashSet<Uri> _uris;
static HttpClientHander()
{
_httpClientsPool = new ConditionalWeakTable<Uri, HttpClientHander>();
_uris = new HashSet<Uri>();
SetupGlobalPoolFinalizer();
}
private DateTime _delayFinalization = DateTime.MinValue;
private bool _isDisposed = false;
public static HttpClientHandle GetHttpClientHandle(Uri baseUrl)
{
HttpClientHander httpClient = _httpClientsPool.GetOrCreateValue(baseUrl);
_uris.Add(baseUrl);
httpClient._delayFinalization = DateTime.MinValue;
httpClient.BaseAddress = baseUrl;
return httpClient;
}
void IDisposable.Dispose()
{
_isDisposed = true;
GC.SuppressFinalize(this);
base.Dispose();
}
~HttpClientHander()
{
if (_delayFinalization == DateTime.MinValue)
_delayFinalization = DateTime.UtcNow;
if (DateTime.UtcNow.Subtract(_delayFinalization) < base.Timeout)
GC.ReRegisterForFinalize(this);
}
private static void SetupGlobalPoolFinalizer()
{
AppDomain.CurrentDomain.ProcessExit +=
(sender, eventArgs) => { FinalizeGlobalPool(); };
}
private static void FinalizeGlobalPool()
{
foreach (var key in _uris)
{
HttpClientHander value = null;
if (_httpClientsPool.TryGetValue(key, out value))
try { value.Dispose(); } catch { }
}
_uris.Clear();
_httpClientsPool = null;
}
}

    var gestionnaire = HttpClientHander.GetHttpClientHandle(new Uri("url de base")).

    • HttpClient, comme une interface, ne peut pas appeler dispose().
    • Dispose() sera appelée dans un mode différé par le Garbage Collector.
      Ou quand le programme nettoie l'objet par le biais de son destructeur.
    • Utilise les Références Faibles + retard de nettoyage de la logique de sorte qu'il reste en vigueur tant qu'il est être réutilisés fréquemment.
    • Il n'alloue un nouveau HttpClient pour chaque URL de base est passé. Les raisons expliquées par Ohad Schneider réponse ci-dessous. Le mauvais comportement lors de la modification de l'url de base.
    • HttpClientHandle permet de se moquer dans les tests
    • Parfait. Je vois que vous appelez Dispose sur la méthode que vous vous inscrivez sur GC. Cela devrait être classé plus haut sur le dessus.
    • Notez que HttpClient n'mise en commun de ressources par l'URL de base. Donc, si vous êtes à frapper des milliers de différents sites web dans une liste, vos performances se dégradent sans le nettoyage de ces sites. Cela offre la possibilité de disposer chaque base-url. Toutefois, si vous êtes seulement en utilisant un site web, il peut être uniquement pour des raisons académiques pour appeler dispose.
    InformationsquelleAutor TamusJRoyce
  9. 1

    À l'aide de l'injection de dépendance dans votre constructeur permet de gérer la durée de vie de votre HttpClient plus facile la prise de la durée de vie managemant en dehors du code qui en a besoin et en les rendant facilement changable à une date ultérieure.

    Ma préférence est pour créer un autre client http classe qui hérite de HttpClient une fois par cible critère de domaine et ensuite faire un singleton à l'aide de l'injection de dépendance. public class ExampleHttpClient : HttpClient { ... }

    Puis-je prendre un constructeur de dépendance sur la coutume http client dans les classes de service où j'ai besoin d'accéder à l'API. Cela résout le problème de durée de vie et a des avantages quand il s'agit de regroupement de connexion.

    Vous pouvez voir un exemple de réponse similaire à https://stackoverflow.com/a/50238944/3140853

    InformationsquelleAutor alastairtree
  10. -3

    Je pense que l'on devrait utiliser le pattern singleton pour éviter d'avoir à créer des instances de la HttpClient et la fermeture de tous les temps. Si vous êtes en utilisant .Net 4.0, vous pourriez utiliser un exemple de code ci-dessous. pour plus d'informations sur le pattern singleton vérifier ici.

    class HttpClientSingletonWrapper : HttpClient
{
private static readonly Lazy<HttpClientSingletonWrapper> Lazy= new Lazy<HttpClientSingletonWrapper>(()=>new HttpClientSingletonWrapper()); 
public static HttpClientSingletonWrapper Instance {get { return Lazy.Value; }}
private HttpClientSingletonWrapper()
{
}
}

    Utiliser le code comme ci-dessous.

    var client = HttpClientSingletonWrapper.Instance;
    • Quelque chose à regarder dehors pour quand ce faire (et d'autres mécanismes similaires): "Tout les membres de l'instance ne sont pas garantis pour être thread-safe."
    • Si cette réponse est correcte ou non doit être totalement dépendant de ce que l'application que vous souhaitez utiliser HttpClient de. Si vous avez une application web et de créer un singleton HttpClient que toutes les requêtes web partagerait ensuite de vous êtes potentiellement va obtenir beaucoup d'exceptions de connexion (en fonction de la popularité de votre site web est! :-)). (Voir David Faivre réponse)
    InformationsquelleAutor yayadavid