Faraday: Pourquoi n'y a-t-il pas de méthode de fermeture ?

Ça a l'air bien. Nous accepterons volontiers un patch testé pour cela.

Je n'ai actuellement pas le temps et je ne suis pas dans la source faraday. J'y reviendrai si cela change :)

Ce serait bien si vous gardiez cela ouvert comme rappel.

Cool. Cela peut en fait être plus facile dans Faraday 0.10/1.0 lorsque nous abandonnons le constructeur actuel inspiré du rack. Le "constructeur de rappel" a un lien direct vers un adaptateur, ce qui facilite le proxy de l'appel #close vers l'adaptateur. Actuellement, vous devez parcourir le middleware à la recherche de tout ce qui répond à #close . En fait, ce n'est pas une idée horrible, cela donne également au middleware la possibilité de nettoyer toutes les ressources.

Gardez à l'esprit que net-http-persistent _peut_ sembler ne pas réutiliser les connexions, mais c'est le cas. Toutes les instances de Net::HTTP::Persistent utilisent le même pool de connexions en interne.

J'ai également cherché un moyen de fermer les connexions.
Je comprends la difficulté de fournir une interface cohérente car chaque bibliothèque a une méthode différente ( shutdown pour net-http-persistent, finish pour net-http, close pour excon ) pour fermer les connexions après leur établissement.
Cependant, ce serait une grande victoire de pouvoir appeler Faraday::Connection#close pour fermer activement la connexion pour tous les adaptateurs et middleware pris en charge.

Cela n'arrivera probablement pas à Faraday. #454 explique la décision de commencer à se concentrer sur Hurley (essentiellement une réécriture). Le problème est que votre Faraday::Connection ne sait pas quel middleware est la connexion réelle. C'est juste une pile de procs. Hurley résout ce problème en séparant l'adaptateur de connexion de la pile de rappels. Cependant, l'interface actuelle de Hurley ne prend pas non plus en charge la notion d'opération de fermeture :) Mais en raison de sa conception, il est beaucoup plus facile de l'ajouter à Hurley que Faraday. J'essaierai d'examiner cela bientôt et de vous envoyer un ping sur le PR si vous êtes intéressé.

Merci @technoweenie ce serait génial et cette explication a du sens.

D'après ce que j'ai compris, Hurley est mort. Avez-vous des idées sur la réouverture de cette demande si c'est vrai ? Nous aimerions avoir une méthode proche, car nous rencontrons beaucoup d'erreurs "Net::HTTP::Persistent::Error: too many connection reset (due to Connection reset by peer - Errno::ECONNRESET)" et j'aimerais essayer de forcer la fermeture de la connexion par la suite, mais ce problème rend cela difficile.

Salut tout le monde,

Je serais heureux de ramener cela à la vie pour une future version de Faraday.
Personnellement, j'aime l'idée d'avoir une méthode dans tous les middlewares qui pourrait être appelée lorsque la connexion est fermée (une sorte de rappel, si vous voulez).

Heureux d'en discuter ici si quelqu'un a un peu de temps pour y travailler

Le problème est que votre Faraday::Connection ne sait pas quel middleware est la connexion réelle.

Nous le faisons dans async-http , et nous passons simplement la méthode #close à tous les middlewares afin qu'ils puissent faire leur propre travail, par exemple libérer des caches, peu importe.

Veuillez intégrer cette partie de la version 1.0. Même si ce n'est pas implémenté dans tous les middleware.

Vous devez également documenter la sécurité des threads du middleware et les attentes du code utilisateur, c'est-à-dire les adaptateurs censés être thread-safe, invoqués à partir de différents threads, etc. Tout cela fait partie de la gestion du cycle de vie.

par exemple dans async-http, nous ne partageons pas de pools persistants entre les threads. Dans CRuby, nous créons des processus séparés dans Falcon, ce qui évite principalement ces problèmes, mais dans JRuby, nous n'avons que des threads différents.

Il y a un effort dans #1024 pour être plus intelligent quant au moment de créer des objets de connexion, s'il faut les mettre en commun, etc. Cela pourrait être un cas où un Faraday::Connection#close pourrait fermer le bon objet de connexion http.

J'aime beaucoup cette idée aussi :

et nous passons simplement la méthode #close à tous les middlewares afin qu'ils puissent faire leur propre travail, par exemple libérer des caches, peu importe.

J'aimerais vraiment intégrer tout cela à la version 1.0, mais j'ai besoin d'aide en termes de contributions au code et de commentaires des utilisateurs.

Quant à la sécurité des fils, il n'y a malheureusement aucune garantie. Idéalement, j'aimerais arriver à un endroit où Faraday::Connection , y compris les middleware et les adaptateurs, sont tous thread-safe.

Si vous ne pouvez pas garantir la sécurité des threads, pourquoi ne pas ajouter un middleware tout en haut de la pile avec un mutex réentrant pour vous assurer qu'un seul thread peut utiliser le reste de la pile à la fois.

En ce qui concerne close, pourquoi ne pas simplement ajouter ceci dans la classe de base pour le middleware. L'implémentation par défaut peut simplement appeler close sur le prochain middleware.

Qu'en penses-tu?

Pouvez-vous changer le jalon en 1.0 ?

et nous passons simplement la méthode #close à tous les middlewares afin qu'ils puissent faire leur propre travail, par exemple libérer des caches, peu importe.

J'ai une idée sur la façon de l'implémenter, mais ce ne sera pas à l'épreuve des balles en raison de la liberté que nous donnons de pousser n'importe quoi dans la pile middleware dans la mesure où il répond à call . Cela devrait quand même fonctionner correctement dans 90% des cas.

En ce qui concerne la sécurité des threads, même si nous aimerions y arriver, je suppose que notre plus gros problème est le manque de quelqu'un dans l'équipe de base suffisamment informé sur le sujet pour nous aider à y parvenir.

@iMacTia et mes relations publiques ?

Il existe maintenant une méthode #close , tout cela grâce au #1069. L'implémenter correctement dans un middleware (tel que l'adaptateur net-http-persistent) doit être laissé pour des demandes d'extraction séparées.

Il y a un effort dans https://github.com/lostisland/faraday/issues/1024 pour refactoriser les adaptateurs pour permettre les instances client mises en cache (comme dans l'adaptateur net-http-persistent), mais de manière cohérente sur tous les adaptateurs cela pourrait en profiter.