Faraday: Por que não existe um método de fechamento?

Parece bom. Aceitaremos com prazer um patch testado para isso.

Atualmente não tenho tempo e não estou na fonte faraday. Voltarei a ele se isso mudar :)

Seria bom se você mantivesse isto aberto como um lembrete.

Legal. Na verdade, pode ser mais fácil no Faraday 0.10 / 1.0 quando abandonamos o atual construtor inspirado em rack. O "construtor de retorno de chamada" tem um link direto para um adaptador, facilitando o proxy da chamada #close para o adaptador. Atualmente, você teria que percorrer o middleware procurando por qualquer coisa que responda a #close . Na verdade, essa não é uma ideia horrível, dá ao middleware a chance de limpar todos os recursos também.

Tenha em mente que net-http-persistent _pode_ parecer não estar reutilizando conexões, mas está. Todas as instâncias de Net :: HTTP :: Persistent usam o mesmo pool de conexão internamente.

Tenho procurado uma maneira de fechar conexões também.
Eu entendo a dificuldade de fornecer uma interface consistente, pois cada biblioteca tem um método diferente ( shutdown para net-http-persistent, finish para net-http, close para excon ) para fechar conexões depois de estabelecidas.
No entanto, seria uma grande vitória poder chamar Faraday::Connection#close para fechar ativamente a conexão para todos os adaptadores e middleware suportados.

Provavelmente, isso não acontecerá em Faraday. # 454 explica a decisão de começar a focar em Hurley (essencialmente uma reescrita). O problema é que seu Faraday::Connection não sabe qual middleware é a conexão real. É apenas uma pilha de procs. Hurley resolve isso separando o adaptador de conexão da pilha de retornos de chamada. No entanto, a interface atual de Hurley também não suporta a noção de uma operação de fechamento :) Mas devido ao seu design, é muito mais fácil adicioná-lo a Hurley do que Faraday. Vou tentar investigar isso em breve e enviar um ping para você no PR, se estiver interessado.

Obrigado @technoweenie, isso seria ótimo e essa explicação faz sentido.

Pelo que entendi, Hurley está morto - alguma ideia sobre reabrir esse pedido, se for verdade? Adoraríamos ter um método de fechamento, já que estamos encontrando muitos erros "Net :: HTTP :: Persistent :: Error: muitas reconfigurações de conexão (devido à reconfiguração de conexão pelo par - Errno :: ECONNRESET)" e gostaria de tentar forçar o fechamento da conexão depois, mas esse problema torna isso desafiador.

Olá a todos,

Eu ficaria feliz em trazer isso de volta à vida em um futuro lançamento de Faraday.
Eu pessoalmente gosto da ideia de ter um método em todos os Middlewares que possa ser chamado quando a conexão for fechada (algum tipo de callback, se você quiser).

Fico feliz em discutir sobre isso aqui, se alguém tiver algum tempo para trabalhar nisso 👍

O problema é que seu Faraday :: Connection não sabe qual middleware é a conexão real.

Fazemos isso em async-http , e apenas passamos o método #close todos os middlewares para que eles possam fazer seu próprio trabalho, por exemplo, liberar caches, qualquer coisa.

Faça esta parte da versão 1.0. Mesmo que não seja implementado em todos os middlewares.

Você também deve documentar a segurança de thread do middleware e as expectativas do código do usuário, ou seja, se espera que os adaptadores sejam thread safe, invocados a partir de threads diferentes, etc. Tudo isso faz parte do gerenciamento do ciclo de vida.

por exemplo, em async-http, não compartilhamos pools persistentes entre threads. No CRuby, geramos processos separados no Falcon, o que evita esses problemas, mas no JRuby temos apenas threads diferentes.

Há um esforço no # 1024 para ser mais inteligente sobre quando criar objetos de conexão, se agrupá-los, etc. Isso poderia ser um caso em que Faraday::Connection#close poderia fechar o objeto de conexão http correto.

Também gosto muito desta ideia:

e apenas passamos o método #close todos os middlewares para que eles possam fazer seu próprio trabalho, por exemplo, liberar caches, qualquer coisa.

Eu realmente gostaria de colocar tudo isso no 1.0, mas preciso de ajuda na forma de contribuições de código e feedback do usuário.

Quanto à segurança do fio, infelizmente não há garantias. Idealmente, eu gostaria de chegar a um lugar onde Faraday::Connection , incluindo middleware e adaptadores, sejam todos thread-safe.

Se você não pode garantir a segurança do thread, por que não adiciona um middleware no topo da pilha com um mutex reentrante para garantir que apenas um thread possa usar o resto da pilha por vez?

Em relação a fechar, por que você simplesmente não adiciona isso na classe base para middleware. A implementação padrão pode apenas chamar close no próximo middleware.

O que você acha?

Você pode alterar o marco para 1.0?

e nós apenas passamos o método #close por todos os middlewares para que eles possam fazer seu próprio trabalho, por exemplo, liberar caches, qualquer coisa.

Eu tenho uma ideia de como implementar isso, no entanto, não será à prova de balas devido à liberdade que oferecemos para empurrar qualquer coisa na pilha de middleware desde que responda call . Ele ainda deve funcionar bem em 90% dos casos.

Com relação à segurança do thread, embora adoraríamos chegar lá, acho que nosso maior problema é a falta de alguém na equipe principal com conhecimento suficiente sobre o assunto para nos ajudar a alcançá-lo.

@iMacTia e meu PR?

Existe um método #close agora, tudo graças a # 1069. A implementação adequada no middleware (como o adaptador net-http-persistent) deve ser deixada para solicitações pull separadas.

Há um esforço em https://github.com/lostisland/faraday/issues/1024 para refatorar os adaptadores para permitir instâncias do cliente em cache (como no adaptador net-http-persistent), mas de forma consistente em todos os adaptadores que poderia se beneficiar.