Ir para conteúdo
  • Cadastre-se

dev botao

Erro Retorno de Queda de Internet


  • Este tópico foi criado há 2802 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro

Olá a todos,

Meu aplicativo emissor de NFC-e ao detectar queda de internet, através da exceção disparada pelo componente, efetua automaticamente o envio em contigência.

Configurei a propriedade Webservices.TimeOut do ACBrNFE em 5000, WebServices.Tentativas em 1 e WebServices.IntervaloTentativas em 1000.

Reparei nos clientes que quando cai a internet, as vezes a exceção do componente é disparada em 5 segundos conforme configurado no timeout e logo em seguida imprimo a contingência, o cenário ideal inclusive. Mas as vezes leva bem mais que 5 segundos para o componente disparar a exceção, leva 12 segundos ou até mais. Para detalhar melhor a causa do problema gerei um log para armazenar o retorno de cada exceção disparada quando a internet cai e é impresso a contingência. A conclusão que cheguei foi de que:

  • Erro 12002 - The operation timed out: Ocorre em RIGOROSAMENTE 5 segundos.
  • Erro 12007 - The server name or address could not be resolved: Nesse caso ocorre entre 12 a 18 segundos.

Ao menos hoje em um cliente, foram as únicas exceções de queda de internet que foram registradas. Como podem observar o erro 12002 ocorre em exatos 5 segundos, respeitando o TimeOut configurado. Já o erro 12007 não segue tal propriedade.

Como afirmei anteriormente, preciso que qualquer exceção de queda da internet seja disparada em no máximo 5 segundos para que tão logo em seguida já emita a contingência e evite filas no cliente, que as vezes tem que esperar quase 20 segundos até o componente disparar a exceção e eu poder gerar em contingência.

Como tratar o tempo da 12007 e outras diferentes da 12002?

Desde já agradeço a atenção

 

Link para o comentário
Compartilhar em outros sites

  • Consultores

Olá doidopb,

 

Preciso dizer que NF-e não é o meu forte, talvez outros possam me corrigir aqui.

Acredito que as diferenças se devam à implementação e à quando o erro é retornado. Outra coisa importante, você não deve levar todos os TimeOuts rigorosamente, pois dependem de como foram implementados.

Então vamos por parte. Todos esses erros são da WinInet. Isso significa que o ACBr não está emitindo o erro. Apenas passando pra você o erro que ele encontrou enquanto estava tentando fazer o que você pediu. Sendo assim, pode ser que a interface retorne o erro em lugares diferentes, e com um tempo de resposta diferente.

No entanto, veja a seguinte implementação de TNFeRetRecepcao.Executar.

NOTA IMPORTANTE: Não estou dizendo que é esse o código que é executado, pois você não disse exatamente o que fez, nem colocou o exatamente onde o erro acontece... mas serve para ilustrar o que quero dizer da implementação.

function TNFeRetRecepcao.Executar: Boolean;
var
  IntervaloTentativas, Tentativas: integer;
begin
  Result := False;

  TACBrNFe(FPDFeOwner).SetStatus(stNfeRetRecepcao);
  try
    Sleep(FPConfiguracoesNFe.WebServices.AguardarConsultaRet);

    Tentativas := 0;
    IntervaloTentativas := max(FPConfiguracoesNFe.WebServices.IntervaloTentativas, 1000);

    while (inherited Executar) and
      (Tentativas < FPConfiguracoesNFe.WebServices.Tentativas) do
    begin
      Inc(Tentativas);
      sleep(IntervaloTentativas);
    end;
  finally
    TACBrNFe(FPDFeOwner).SetStatus(stIdle);
  end;

  if FNFeRetorno.CStat = 104 then  // Lote processado ?
    Result := TratarRespostaFinal;
end;

Note que no loop, ele verifica primeiro se a implementação de Executar herdado da classe é verdadeira, para depois avaliar o número de tentativas:

    while (inherited Executar) and
      (Tentativas < FPConfiguracoesNFe.WebServices.Tentativas) do
    begin
      Inc(Tentativas);
      sleep(IntervaloTentativas);
    end;

Caso essa implementação tenha alguma espera, isso pode explicar o motivo de você estar esperando alguns segundos a mais do que o esperado. Veja: Quando inherited executar falha de primeira, o tempo gasto é exatamente 5 segundos de timeOut. Mas levando em conta que não falhasse de primeira, daria exatamente 12 segundos para a sua configuração atual.

Mais uma vez, não estou dizendo que é esse o código que é executado, pois você não disse exatamente o que fez, nem colocou o exatamente onde o erro acontece... mas serve para ilustrar o que quero dizer da implementação.

Se for um código semelhante, bastaria você mudar o número de tentativas para 0.

Sugiro você tentar isso.

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

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

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Oi EMBarbosa, tudo bom?

Então rapaz, tentei colocar 0 no número de tentativas, mas continua a levar 12 segundos quando o retorno do componente é 12007, quando é 12002 obedece fielmente o tempo configurado em Webservices.TimeOut do ACBrNFE, atualmente 5 segundos. Nesse cliente quando cai a internet, o erro apresentado é 12007 ou 12002, pelo menos até agora.

Meu código é bem simples na verdade.

Primeiro tento efetuar o envio normal:
 

GerarNFCe(IntToStr(cupom), False);
dtm_banco.ACBrNFe1.Enviar(cupom, False, dtm_banco.DFe_Envio);

Logo em seguida, coloco e seguinte tratamento:

except
 on E : Exception do
  if (pos('requisição não enviada', LowerCase(E.Message)) <> 0) or (pos('tempo limite', LowerCase(E.Message)) <> 0) then
   begin
    //dessa vez em contingencia
    GerarNFCe(IntToStr(cupom), True);
    dtm_banco.ACBrNFe1.NotasFiscais.Assinar;
    dtm_banco.ACBrNFe1.NotasFiscais.Validar;
    //depois imprimo 2 vias
    dtm_banco.ACBrNFe1.Danfe.ViaConsumidor := True;
    dtm_banco.ACBrNFe1.NotasFiscais.Imprimir;
    dtm_banco.ACBrNFe1.Danfe.ViaConsumidor := False;
    dtm_banco.ACBrNFe1.NotasFiscais.Imprimir;
   end;

Como pode observar, se disparar uma exceção, ele verifica se trata-se de "requisição não enviada" (referente ao 12007) ou "tempo limite" (referente ao 12002). Só isso.

Funciona perfeito, o problema está no tempo de disparo dessa exceção para que eu possa tratar.

O 12002 dispara conforme o tempo que eu configurar em Webservices.TimeOut do ACBrNFE, atualmente 5 segundos, se eu aumentar para 18 ele aumenta também para 18, para 10 aumenta para 10 e assim vai, perfeitamente ajustável pela propriedade citada do componente. Mas o 12007 não, ele leva em média 12 segundos e pronto, e numa fila de mercado isso é muito.

 

Link para o comentário
Compartilhar em outros sites

  • Consultores

Então, se o número de tentativas não altera o tempo, o problema é saber exatamente onde o componente está recebendo esse erro e se o tempo que ele demora para receber é realmente culpa dele. Acho improvável que seja, pois alterar as propriedades não resolveu o seu problema.

Você conseguiu debugar algum desses problemas e ver exatamente onde ele é levantado? Precisamos de um passo a passo para reproduzir o problema.

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

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

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Entendi.

Como disse esse problema de não seguir o configurado no TimeOut só ocorre com o retorno 12007.

Você não teria como reproduzir esse tipo de exceção, a 12007 especificamente, no envio de uma NFC-e qualquer? Se sim, você vai observar se ela segue o tempo configurado no componente (WebServices.TimeOut) ou não.

De qualquer forma agradeço a sua atenção

Link para o comentário
Compartilhar em outros sites

  • Moderadores

Quanto ao erro:

  • Erro 12007 - The server name or address could not be resolved: Nesse caso ocorre entre 12 a 18 segundos.

Veja que é um erro de DNS, o endereço do site não pode ser encontrado ou resolvido, isso depende do retorno do DNS que pode variar e consequentemente não vai entrar no timeout pois é um erro externo, diferente do erro de timeout que é um erro interno.

Funciona mais ou menos assim:

1. o winnet tenta conectar, nesse caso a conexão vai tentar "sair para o mundo", se não houver conexão com a internet o winnet vai esperar o tempo configurado no timeout para retornar o erro ao componente ACBr.

2. se a conexão conseguiu "sair para o mundo", o DNS vai tentar resolver o endereço passado e encontrar o servidor, neste caso temos o erro 12007 se o DNS não conseguiu resolver ou encontrar o IP resolvido, o tempo aqui já vai depender da estrutura externa e do DNS e não do winnet ou ACBr, depende do retorno do servidor DNS.

Equipe ACBr

Régys Borges da Silveira

http://www.regys.com.br

certificacao delphicertificacao delphi
Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Olá Régys,

Grato pela resposta. Na verdade, pela descrição do erro eu imaginei a mesma coisa que você e aí fiz o seguinte, desconectei o modem da rede para ter certeza de que a conexão não iria conseguir "sair pelo mundo" e forçar o erro de timeout, mas não obtive exito, na verdade mesmo assim continuou o erro 12007 com a sua demora em disparar tal exceção.

Isso em 2 clientes que observei, mercados que atendo. Aí fica aquela lentidão quando a internet cai. Eu até imaginei que pudesse ser algo nas máquinas, mas um mercado possui 6 estações e o outro 3, acho que seria muita coincidência pois acontece em todas as máquinas.

Teria alguma orientação a me passar para tentar amenizar tal demora no disparo dessa exceção?

 

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Olá Régys, desculpe a demora. Não, não tenho... Na verdade eu simplesmente uso o DNS da Google, 8.8.8.8 e 8.8.4.4.

O que eu fiz, supus que isso fosse a causa do problema, de repente mesmo caindo a internet ele tentaria acessar o DNS do google e resolver o nome, o que seria improvável na verdade, pois trata-se de um IP público onde ele perceberia que não tem acesso dado a falta de internet e "de cara" não tentaria resolver.

Mesmo assim, a nível de teste, coloquei o endereço do modem como DNS, 192.168.1.1, e desconectei o sinal ADSL (Velox), permaneceu o erro 12007, ele tenta resolver. Desconectei então o modem, erro 12007, tenta resolver.

Não sei se esse problema ocorre em outros clientes ou está isolado nesses 2. Vou checar nos outros clientes e posto aqui, mas se com sua experiência puder me fornecer alguma dica ou recomendar algum(ns) teste(s), te agradeço.

Abraços

Link para o comentário
Compartilhar em outros sites

  • Moderadores

Você poderia tentar pingar um endereço externo e ver o tempo de resposta com e sem conexão para ter uma ideia do tempo que demora a retornar que não há conexão, é um teste simples, mas pode ajudar a verificar se tem algo no caminho atrasando.

Eu já vi alguns antivirus causarem demora nisso, pois eles interceptam o trafego de rede e fazem um tratamento próprio, é outro ponto a se verificar, eu uso por exemplo o kaspersky completo, ele possui esse tipo de verificação e acaba influenciando nos tempos de resposta.

Equipe ACBr

Régys Borges da Silveira

http://www.regys.com.br

certificacao delphicertificacao delphi
Link para o comentário
Compartilhar em outros sites

  • 2 meses depois ...
  • Membros Pro

Olá Régys,

Desculpe a demora, mas preciso voltar nesse tópico. Estou com mais clientes de mercado e o erro mencionado nesse tópico está se tornando mais evidente.

Realizei o teste do Ping conforme me orientou, leva um tempo de 4,5 segundos em média para retornar "esgotado o tempo limite".

Hoje estou com 6 mercados, e em todos pude evidenciar tal erro, dado o maior volume de vendas.  Nos outros clientes nunca reparei pela questão do volume baixo de vendas, aí quando caia a internet não ficava tão evidenciado a demora de 12 segundos e eles não reclamavam, mas com os mercados ativos houve reclamações e eu pude constatar que esse problema se dá neles e na maioria dos outros clientes menores.

Suponho que deva ser um "pequeno detalhe" para resolver, mas não consegui matar essa charada, e fica complicado quando a internet cai, pois sabem como os caixas são "impacientes".

Peço mais uma vez a sua ajuda.

Desde já agradeço a sua atenção 

 

Link para o comentário
Compartilhar em outros sites

  • Consultores
17 minutos atrás, doidopb disse:

Realizei o teste do Ping conforme me orientou, leva um tempo de 4,5 segundos em média para retornar "esgotado o tempo limite".

Neste caso, o problema é da rede de seu cliente. Tente reproduzir o problema na sua máquina, talvez alterando o endereço do webservice para debugar e verificar o motivo de estar demorando...

Uma alternativa é que você poderia adicionar um teste de ping via programação e se não funcionar chamar o modo de contingência.

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

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

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Grato pela dica EMBarbosa, mas como passei lá no início o componente leva 12 segundos em média para gerar a exceção, ao contrário do ping que retornou em 4,5 segundos o erro.

Mas como te disse, não é apenas 1 cliente, dessa vez eu testei com calma e constatei que o problema do 12007 está em todos.

Nos seus clientes ao receber o erro 12007 o componente respeita o tempo do TimeOut?

Editado por doidopb
Link para o comentário
Compartilhar em outros sites

  • Consultores
2 horas atrás, doidopb disse:

Mas como te disse, não é apenas 1 cliente, dessa vez eu testei com calma e constatei que o problema do 12007 está em todos.

Nos seus clientes ao receber o erro 12007 o componente respeita o tempo do TimeOut?

Nos meus clientes esse erro não acontece normalmente. Quando acontece eles sabem que é a internet deles que deu problema... Por outro lado, onde a questão de rede é muito importante e achamos necessário, nós fazemos o teste do ping antes.

2 horas atrás, doidopb disse:

Grato pela dica EMBarbosa, mas como passei lá no início o componente leva 12 segundos em média para gerar a exceção, ao contrário do ping que retornou em 4,5 segundos o erro.

E foi por isso que eu sugeri pra você tentar reproduzir na sua máquina o problema usando um endereço não existente e avaliar onde no código o componente está gastando o tempo a mais. Você deve entender que o componente não faz um ping e exatamente por isso pode gastar mais ou menos tempo.

Minha sugestão do ping foi para que você tenha uma solução imediata para seus clientes. Caso contrário, esperar até identificarmos se é realmente um problema no componente, neste caso onde é o problema e daí só então a correção...

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

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

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Consultores
2 horas atrás, doidopb disse:

Mas como te disse, não é apenas 1 cliente, dessa vez eu testei com calma e constatei que o problema do 12007 está em todos.

Nos seus clientes ao receber o erro 12007 o componente respeita o tempo do TimeOut?

Nos meus clientes esse erro não acontece normalmente. Quando acontece eles sabem que é a internet deles que deu problema... Por outro lado, onde a questão de rede é muito importante e achamos necessário, nós fazemos o teste do ping antes.

2 horas atrás, doidopb disse:

Grato pela dica EMBarbosa, mas como passei lá no início o componente leva 12 segundos em média para gerar a exceção, ao contrário do ping que retornou em 4,5 segundos o erro.

E foi por isso que eu sugeri pra você tentar reproduzir na sua máquina o problema usando um endereço não existente e avaliar onde no código o componente está gastando o tempo a mais. Você deve entender que o componente não faz um ping e exatamente por isso pode gastar mais ou menos tempo.

Minha sugestão do ping foi para que você tenha uma solução imediata para seus clientes. Caso contrário, esperar até identificarmos se é realmente um problema no componente, neste caso onde é o problema e daí só então a correção...

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

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

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Membros Pro
Nos meus clientes esse erro não acontece normalmente. Quando acontece eles sabem que é a internet deles que deu problema... Por outro lado, onde a questão de rede é muito importante e achamos necessário, nós fazemos o teste do ping antes.

Você comentou que quando acontece esse erro eles sabem que é de internet. Mas o erro é o 12007? E se sim, leva esse tempo de 12 segundos para disparar a exceção? Outro detalhe, você dispara a sua contingência via teste de ping como sugeriu ou faz como eu analisando o retorno da exceção do componente? Se possível, poderia postar o exemplo do seu código?

Desde já agradeço a dica do teste do ping, mas como isso vai alterar o meu código (que é disparado pela exceção do componente e aí sim gera a contingência) seria mais viável eu descobrir o que faz essa exceção demorar tanto tempo a disparar, se algo nas redes dos clientes ou algum "detalhe" no componente.

Acabo de reproduzir o problema em minha máquina de desenvolvimento, segue o que fiz e minhas conclusões:

Coloquei um roteador wifi distribuindo a internet para esse micro sem fio, o roteador puxa a internet através de um modem ADSL ligado diretamente ao mesmo. Ao desligar o modem ou desligar apenas o sinal ADSL (erros típicos nos clientes) o erro 12007 sempre é o retornado. Tentei realizar o ping na máquina de teste para www.uol.com.br, só que dessa vez não deu "Esgotado o tempo limite", suponho que pelo fato do cache DNS estar vazio nesse momento, obtive o erro "A solicitação ping não pôde encontrar o host www.uol.com.br. Verifique o nome e tente novamente.", que creio se tratar do 12007, e dessa vez tive a mesma demora de 12 segundos.

Creio que o problema não está no componente, e sim na demora do Windows de retornar tal erro (12007) para que então o componente possa tratar o mesmo. A questão é que quando cai a internet, 90% dos erros é o 12007 (de acordo com meus logs) e com isso tenho esse problema de demora. Daí minha dúvida, como vocês tratam seus erros de internet quando ocorrem? Como eu, através da exceção do componente, só que com um detalhe a mais? Ou através de outro método, como o teste do ping citado pelo EMBarbosa?

Desde já agradeço a atenção de todos.

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.