Faraday: Почему нет близкого метода?

Звучит отлично. Мы с радостью примем для этого проверенный патч.

У меня сейчас нет времени и я не в фарадеевском источнике. Я вернусь к нему, если это изменится :)

Было бы неплохо, если бы вы оставили это открытым в качестве напоминания.

Прохладный. На самом деле это может быть проще в Faraday 0.10 / 1.0, когда мы откажемся от текущего конструктора, вдохновленного рэком. «Конструктор обратных вызовов» имеет прямую ссылку на адаптер, что упрощает проксирование вызова #close адаптеру. В настоящее время вам придется перебирать промежуточное программное обеспечение в поисках всего, что отвечает на #close . На самом деле, это неплохая идея, она дает промежуточному программному обеспечению возможность очищать и любые ресурсы.

Имейте в виду, что net-http-persistent _ может выглядеть так, как будто он не использует повторно соединения, но это так. Все экземпляры Net :: HTTP :: Persistent внутренне используют один и тот же пул соединений.

Я тоже искал способ закрыть связи.
Я понимаю сложность предоставления согласованного интерфейса, поскольку каждая библиотека имеет свой метод ( shutdown для net-http-persistent, finish для net-http, close для excon ) для закрытия соединений после их установления.
Однако было бы большим выигрышем иметь возможность вызвать Faraday::Connection#close чтобы активно закрыть соединение для всех поддерживаемых адаптеров и промежуточного программного обеспечения.

С Фарадеем, скорее всего, этого не случится. # 454 объясняет решение сосредоточиться на Херли (по сути, это переписывание). Проблема в том, что ваш Faraday::Connection не знает, какое промежуточное ПО является фактическим соединением. Это просто стек проков. Hurley решает эту проблему, отделяя адаптер подключения от стека обратных вызовов. Однако текущий интерфейс Hurley также не поддерживает понятие закрытой операции :) Но из-за его дизайна гораздо проще добавить его к Hurley, чем к Faraday. Я постараюсь разобраться в этом в ближайшее время и связать вас с PR, если вам интересно.

Спасибо @technoweenie, это было бы здорово, и это объяснение имеет смысл.

Насколько я понимаю, Херли мертв - есть ли мысли о повторном открытии этого запроса, если это правда? Нам бы хотелось иметь метод закрытия, поскольку мы сталкиваемся с множеством ошибок типа «Net :: HTTP :: Persistent :: Error: слишком много сбросов соединения (из-за сброса соединения одноранговым узлом - Errno :: ECONNRESET)». и потом хотел бы попробовать принудительно закрыть соединение, но эта проблема усложняет задачу.

Всем привет,

Я был бы счастлив вернуть это к жизни для будущего релиза Фарадея.
Мне лично нравится идея иметь метод во всех промежуточных программах, который может вызываться при закрытии соединения (какой-то обратный вызов, если хотите).

Рад обсудить это здесь, если у кого-то есть время поработать над этим 👍

Проблема в том, что ваш Faraday :: Connection не знает, какое промежуточное ПО является фактическим соединением.

Мы делаем это в async-http , и мы просто передаем метод #close все промежуточные программы, чтобы они могли выполнять свою работу, например, освобождать кеши и т. Д.

Пожалуйста, сделайте эту часть версии 1.0. Даже если это реализовано не во всем промежуточном программном обеспечении.

Вы также должны задокументировать потокобезопасность промежуточного программного обеспечения и ожидания от пользовательского кода, то есть должны ли адаптеры быть поточно-ориентированными, запускаться из разных потоков и т. Д. Все это является частью управления жизненным циклом.

например, в async-http мы не разделяем постоянные пулы между потоками. В CRuby мы создаем отдельные процессы в Falcon, что в основном позволяет избежать этих проблем, но в JRuby у нас есть только разные потоки.

В # 1024 есть попытка понять, когда создавать объекты соединения, объединять ли их в пул и т. Д. Это может быть в случае, когда Faraday::Connection#close может закрыть правильный объект HTTP-соединения.

Мне тоже очень нравится эта идея:

и мы просто передаем метод #close все промежуточное ПО, чтобы они могли выполнять свою работу, например, освобождать кеши и т. д.

Мне бы очень хотелось, чтобы все это было в 1.0, но мне нужна помощь в виде добавления кода и отзывов пользователей.

Что касается потоковой безопасности, то, к сожалению, никаких гарантий нет. В идеале я хотел бы попасть в место, где Faraday::Connection , включая промежуточное ПО и адаптеры, являются потокобезопасными.

Если вы не можете гарантировать безопасность потоков, почему бы вам не добавить промежуточное ПО на самом верху стека с повторно входящим мьютексом, чтобы гарантировать, что только один поток может использовать остальную часть стека за раз.

Что касается закрытия, почему бы вам просто не добавить это в базовый класс для промежуточного программного обеспечения. Реализация по умолчанию может просто вызвать close для следующего промежуточного программного обеспечения.

Что вы думаете?

Можете ли вы изменить веху на 1.0?

и мы просто передаем метод #close всем промежуточным программам, чтобы они могли выполнять свою работу, например, освобождать кеши и т. д.

У меня есть идея, как это реализовать, однако это не будет пуленепробиваемым из-за свободы, которую мы даем, чтобы протолкнуть что-либо в стеке промежуточного программного обеспечения, если оно отвечает call . Тем не менее, в 90% случаев он должен работать нормально.

Что касается потоковой безопасности, хотя мы бы хотели этого достичь, я думаю, что нашей самой большой проблемой является отсутствие в основной команде человека, достаточно осведомленного в этом вопросе, чтобы помочь нам в этом.

@iMacTia как насчет моего пиара?

Теперь есть метод #close , все благодаря # 1069. Его правильную реализацию в промежуточном программном обеспечении (например, в адаптере net-http-persistent) следует оставить для отдельных запросов на вытягивание.

В https://github.com/lostisland/faraday/issues/1024 делается попытка рефакторинга адаптеров, чтобы разрешить кэшированные экземпляры клиентов (например, в адаптере net-http-persistent), но последовательно для всех адаптеров. это может принести пользу.