Nfce Timeout

[André Ferreira de Moraes]

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.

[Dércio Luis Zanatta]

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 ?

[Daniel Simoes]

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

[Dércio Luis Zanatta]

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 !
 

[Dércio Luis Zanatta]

No post anterior faltou ainda a linha:

FHTTP.Sock.ConnectionTimeout:=FpDFeSSL.TimeOut ;

[Dércio Luis Zanatta]

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 ..

[Daniel Simoes]

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

[Dércio Luis Zanatta]

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 !

[Dércio Luis Zanatta]

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

 

[Daniel Simoes]

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

[Dércio Luis Zanatta]

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 ?

 

[Daniel Simoes]

Eu creio que seja algo no meio da infraestrutura de TI, do cliente 

[Dércio Luis Zanatta]

16 minutos atrás, Daniel Simoes disse:

Eu creio que seja algo no meio da infraestrutura de TI, do cliente 

O fato é que o problema ocorre em todos os clientes, incluisve aqui na empresa me homologação !

[Dércio Luis Zanatta]

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 ?

 

[Daniel Simoes]

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

[Dércio Luis Zanatta]

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 ?

 

[Daniel Simoes]

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"

[Dércio Luis Zanatta]

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.

 

[Daniel Simoes]

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

Verifique as versões das suas DLLs 

[Dércio Luis Zanatta]

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.

 

[Dércio Luis Zanatta]

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 2 Dezembro, 2016 por Dércio Luis Zanatta

[Daniel Simoes]

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 

[Dércio Luis Zanatta]

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 !

[Dércio Luis Zanatta]

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.