Ir para conteúdo
  • Cadastre-se

dev botao

Nfce Timeout


Ver Solução Respondido por Italo Giurizzato Junior,
  • Este tópico foi criado há 2667 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Moderadores

Aqui pra mim respeita o tempo q coloco no ACBrMonitor. Testei colocando 5, 10 e 30 e em todos os casos quando configuro o endereço do status de serviço para o google o erro é retornado conforme o tempo configurado.

djsystem-logo.png
 youtube.png facebook.png instagram.png linkedin.png
André Ferreira de Moraes | Analista de Sistemas
www.djsystem.com.br | www.djpdv.com.br
www.tefhouse.com.br | www.lambretinha.com.br
Link para o comentário
Compartilhar em outros sites

  • Respostas 98
  • Created
  • Última resposta

Top Posters In This Topic

  • Membros Pro
3 minutos atrás, André Ferreira de Moraes disse:

Aqui pra mim respeita o tempo q coloco no ACBrMonitor. Testei colocando 5, 10 e 30 e em todos os casos quando configuro o endereço do status de serviço para o google o erro é retornado conforme o tempo configurado.

Por que será que para mim não respeita esse Time ?

Link para o comentário
Compartilhar em outros sites

  • Fundadores

Pode ser porque usamos Proxy, aqui na DJSystem... amanhã vou analisar o problema com mais atenção... e tentar implementar um exemplo de envio com Thread

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Bom dia

Fiz uma alteração no 

ACBrDFe\ACBrDFeOpenSSL.pas

na 

procedure TDFeOpenSSL.ConfiguraHTTP(const URL, SoapAction: String;
  MimeType: String); 

Após a linha FHTTP.ProxyPass := FpDFeSSL.ProxyPass;

adicionei
  FHTTP.Sock.NonBlockMode := True;
  FHTTP.Sock.SetTimeout(FpDFeSSL.TimeOut);
  FHTTP.Sock.SetSendTimeout(FpDFeSSL.TimeOut);
  FHTTP.Sock.SetRecvTimeout(FpDFeSSL.TimeOut);
  FHTTP.Sock.SocksTimeout:=FpDFeSSL.TimeOut ;

Ainda estou observando nos clientes, mas pelo que pude verificar ontem a tarde, estão dando muito menos ocorrência de falha de comunicação (Erro Interno: xxxxx HTTP:xxx) e o retorno do erro ocorre bem mais rapidamente.

Vou continuar observando, mas a princípio fez a diferença !
 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

No post anterior faltou ainda a linha:

FHTTP.Sock.ConnectionTimeout:=FpDFeSSL.TimeOut ;

Com essas configurações está respeitando o que eu configuro no TimeOut do componente.

Cheguei a essa conclusão debugando, e ao chegar na procedure 

procedure TBlockSocket.Connect(IP, Port: string);  contida no fonte acbr\fontes\terceiros\synalist\blcksok.pas

na linha:

if FConnectionTimeout > 0 then

notei que essa variáveil FConnectionTimeout continha o valor zero (0)

Procurei onde essa variável é preenchida e vi que ela é alimentada pela propriedade ConnectionTimeout.

Sendo assim, apenas acrescentei a linha

FHTTP.Sock.ConnectionTimeout:=FpDFeSSL.TimeOut ;

Recompilei e então passou a devolver a mensagem de falha de conexão exatamente no tempo que tenho configurado no TimeOut do componente.

Não sei se estou certo, mas espero estar contribuindo com algo ..

Link para o comentário
Compartilhar em outros sites

  • Fundadores

Obrigado André e Dercio, pela persistência e trabalho de pesquisa...

Notei que quem "faz a mágica", é a definição de TimeOut em " FHTTP.Sock.ConnectionTimeout"... com isso a Synapse liga o "NonBlockMode", e consegue detectar o TimeOut independente do Sistema Operacional... (trecho abaixo)

    if FConnectionTimeout > 0 then
    begin
      // connect in non-blocking mode
      b := NonBlockMode;
      NonBlockMode := true;
      SockCheck(synsock.Connect(FSocket, Sin));
      if (FLastError = WSAEINPROGRESS) OR (FLastError = WSAEWOULDBLOCK) then
        if not CanWrite(FConnectionTimeout) then
          FLastError := WSAETIMEDOUT;
      NonBlockMode := b;
    end
    else
      SockCheck(synsock.Connect(FSocket, Sin));  

Já enviei o ajuste para o SVN

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Bom dia pessoal..

Parece que esse problema do Time-out está contornado...  Estou acompanhando e agora está obedencendo o Time-out definido no Componente

O que ainda me parece muito estranho é a quantidade de erros de conexão que acontecem. Nessa filial, desse cliente que estou acompahando, tem uma internet de 40mb, tudo via cabo, sem rádio.. sem proxy, tudo liberado...

Mesmo assim, cerca de 5 % do total das NFCes emitidas no dia apresentam Essa falha de conexão (HTTP:0 u HTTP:500)

Não parece lógico ser um problema de Internet.. porém não sei o que poderia estar causando isso !

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Estou cada vez mais convencido que o FastMM4 tem alguma relação com esses problemas de conexão. Compilei meu aplicativo com o FastMM4.pas no dia 31/10/2016 e o cliente foi atualizado com essa versão no dia 01/11/2016.

Estive fazendo alguns levantamentos agora a pouco....   Antes do dia 01/11/2016 o número de erros de conexão (HTTP:0) era de 8, em média...

a partir do dia 01/11/2016, fica sempre acima de 30 !!

Não parece apenas coincidência.  

O Problema é que não posso tirar o FastMM4 de minha aplicação, pois ele resolveu em 100 % os problemas de "out of memory" que vinham ocorrendo em meu sistema.

"sinuca de bico"  ehehehhee

 

Link para o comentário
Compartilhar em outros sites

  • Fundadores

Eu acho que não há relação... o problema deve ser outro...

Mas é simples de você testar... deixe um PDV com a compilação sem o FastMM e compare os resulatdos

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
11 horas atrás, Daniel Simoes disse:

Eu acho que não há relação... o problema deve ser outro...

Mas é simples de você testar... deixe um PDV com a compilação sem o FastMM e compare os resulatdos

Bom dia

Vou providenciar esse teste Daniel. Lhe ocorre alguma outra idéia da causa dessas falhas de comunicação em uma internet tão estável ?

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

No ACBR existe a propriedade TimeOut e existe a propriedade Tentativas.

Estive olhando nos fontes e vi que o TimeOut é usado no processo de envio, porém não encontrei a propriedade "Tantativas" sendo usada no processo de envio. Onde exatamente ela é usada ?

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
5 minutos atrás, Daniel Simoes disse:

É utilizada na tentativa de leitura do Retorno no modo Assíncrono 

Certo...

Estudando esse probelma, notei que quando ocorre o probelma de conexão HTTP:xxxx , na próxima tentativa de envio vai normal, sem ocorrer o erro.

Pensei em fazer mais de uma tentativa para o envio.., ou seja, ao invés de um TimeOut de 10 seg, fazer duas tentativas de 5 seg..

Estive analisando a seguinte rotina:

function TWebServices.Envia(ALote: String; const ASincrono: Boolean): Boolean;
begin
  FEnviar.Lote := ALote;
  FEnviar.Sincrono := ASincrono;

// Nesse ponto pensei em alterar para executar novamente  Enviar.Executar tantas vezes quanto estiver configurado a propriedade Tentativas do componente.

if not Enviar.Executar then
    Enviar.GerarException( Enviar.Msg );

  if not ASincrono then
  begin
    FRetorno.Recibo := FEnviar.Recibo;
    if not FRetorno.Executar then
      FRetorno.GerarException( FRetorno.Msg );
  end;

  Result := True;
end;
 

Não me sinto muito a vontade em mexer nos fontes do componente ehehehehe

Qual sua opinião sobre isso ?

 

Link para o comentário
Compartilhar em outros sites

  • Fundadores

Tenho receio que isso gera o bloqueio por "Consumo Indevido"...

Você poderia tentar consultar o Status em sua aplicação, antes de enviar a venda...

Veja ainda o evento "OnTransmitError" e o parâmetro que é passado por referencia "Retentar"

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • 2 semanas depois ...
  • Membros Pro

Boa tarde Daniel.

Depois de várias tentativas para tentar descobrir o porque de tantos probelmas de conexão no envio de NFCe, cheguei a uma conclusão. O problema ocorre somente se o componente estiver configurado como Openssl. Fiz um teste agora de manhã.

Em um cliente onde o problema está ocorrendo seguidamente, instalei o certificado A1 (.pfx) no windows e configurei o componente como Capicom, carregando o núemro de série do certificado. A partir dai não ocorre mais nenhum problema de conexão. Todas as NFCes enviadas depois disso autorizam sem problemas.

Sendo assim, acredito que o problema não tenha relação com rede, internet ou Ws da Sefaz, mas sim com a opção OpenSSL.

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
4 minutos atrás, Daniel Simoes disse:

Aqui só usamos OpenSSL... e não temos esse problema...

Verifique as versões das suas DLLs 

Já tinha feito isso.. As DLLs estão atualizadas.

Andei conversando com outros usuário aqui do fórum e alguns deles me disseram que passaram por isso tb e simplesmente desistiram de usar OpenSLL e passar a usar Capicpon. No meu caso fica mais dificel, pois são muitas máquinas para gerenciar o certificado.

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Só para confirmar...

Verifiquei que a data das DLLs que estão na pasta do ACBR são de 01/10/2015 !

Isso está correto ?  Não houve mais atualização de DLLs após essa data ?

na pasta DLL\OpensSSL tem duas verões : 0.9.8.1 e 0.9.8.14  Atualmente estou usando d 0.9.8.14  Isso está correto ?

Editado por Dércio Luis Zanatta
Link para o comentário
Compartilhar em outros sites

  • Fundadores

Sim... essas são as DLLs atuais..

 Para suportar a versão 4.0 precisaremos de novasDLLs 

Você faz uso do evento OnTransmitError  ? ( algo assim )

Nele você poderia implementar, do lado da aplicação, um contador de falhas e Retentar de forma automática 

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro
16 horas atrás, Daniel Simoes disse:

Sim... essas são as DLLs atuais..

 Para suportar a versão 4.0 precisaremos de novasDLLs 

Você faz uso do evento OnTransmitError  ? ( algo assim )

Nele você poderia implementar, do lado da aplicação, um contador de falhas e Retentar de forma automática 

Não uso esse evento. O que eu tentei fazer foi chamar novamente a função enviar quando ocorre o erro de conexão, porém sem secesso, pois retorna erro também na segunda tentativa !

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Boa tarde

Fiz uma alteração aqui que resolveu o problema:

Eu estava utilizando o Componente ACBR dentro de um DataModule carregado na memória. O que fiz foi colocar o Componente em outro Formulário que não fica carregado em memória. Antes de usar o componente faço o carregamento do formulário (Application.CreateForm(TFrmNFce,FrmNFCe) , no final de tudo, depois de enviar, imprimir danfe, enviar e-mail etc... eu dou um Free no formulário (FrmNFCe.Free).

Dessa forma não entra mais nenhuma NFCe em Contingência OFF Line, todas são autorizadas normalmente Utilizando OpensSSL + modo Síncrono.

Link para o comentário
Compartilhar em outros sites


×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.