Dércio Luis Zanatta

embarbosa. A solução de usar o FASTMM4 em minha aplicação acabou definitivamente com os problemas de memória que eu vinha enfrentando, porém notei que depois que passei a usa-lo, estão ocorrendo diversas ocorrências de falhas de comunicação com o WS da SEFAZ .. Apenas para fazer um teste para ter certeza que é esse o problema, gostaria de saber se tem uma maneira de "desativar" o FastMM4 antes de enviar a NFCe e "ativar" novamente depois de receber o retorno.

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

No post anterior faltou ainda a linha: FHTTP.Sock.ConnectionTimeout:=FpDFeSSL.TimeOut ;

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 !

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

Acabei de fazer o teste com ACBRMonitor.. Demora os mesmos 22 seg ! mesmo configurando o Time para 5 seg

Fiz o teste no ACBRDemo Configurei a URL da consulta STatus Serviço com o endereço do GOOGLE Configurei o Time Out do componente como 5000 Fazendo o teste, demora 22 seg para retornar o erro..

Sim, utilizo OpenSSL Posso testar no Demo do ACBR ao invés do monitor ? Para mim testar isso no envio da NFCe ao invés do stauts serviço, eu altero a tag NfeAutorizacao_3.10= ?

Ai que está o estranho André... Eu já configurei 3,5, 10 , etc... Demora sempre 22 seg com esse endereço do google !

Boa tarde Daniel. Fiz o teste que vc sugeriu. Para mim ocorre mensagem de erro depois de 22 seg. mesmo tendo configurado o TimeOut do componente como 3 seg. Vc consegue fazer esse mesmo teste ai ? para vc também demora os 22 seg ou demora o tempo que vc tem configurado no timeout do componente ?

Vc usa como OpensSSL ? Modo Síncrono ? Quando foi a última vez que vc atualizou o ACBR ?

Boa tarde Pessoal, esse post tem por objetivo fazer uma pesquisa entre os usuários do ACBR que fazem envio de NFCe para a SEFAZ - RS Eu estou enfrentando um problema de ocorrer com muita frequência falha de comunicação ao tentar enviar uma NFCe ("erro interno 10060 HTTP:0 ou Erro interno 10091 HTTP:500)" Além de estar ocorrendo com muita frequencia em todos os clientes, em alguns casos em que ha uma demora excessiva para retonrar o erro ( até 3 Min, em alguns casos) A internet do Cliente já foi testada e está super estável. A SEFAZ-RS diz que está autorizando e retornando a resposta em menos de 1 seg. Já tratei o assunto com os mestres aqui do ACBR e eles chegaram a conclusão que não ha o que fazer por parte do componente para resolver o problema. Sendo assim, gostaria de saber se tem mais alguém enfrentando esse problema . Obrigado.

Realmente lametável não ter como controlar o Time Out. Vou fazer um outro post apenas com o objetivo de verificar com outros usuários do RS, se eles também estão enrfentando tais problemas. Por enquanto, muito obrigado.

Ola. Fiz as alterações sugeridas, porém aqui na minha conexão 3G não notei nenhuma melhora... Ainda existe uma demora excessiva.

Obrigado pela dica Daniel, mas eu já consegui simular a demora, mesmo usando a URL da SEFAZ com uma conexão de internet 3G bem lenta.. Simular o problema não é mais problema (com o perdão da redundância) O problema é abortar o processo de envio/Retorno num tempo configurável.. Já fiz deversas tentativas aqui, a que deu melhor resultado foi usar libCapicomDelphiSoap , porém com essa opção ocorre o erro sitado anteriormente em algumas máquinas. Sendo assim, voltei a estaca zero..

TimeOut = 3000 Tentativas = 2 Infelizmente não vou poder usar como libCapicomDelphiSoap Agora está ocorrendo o erro:" A área de dados transferida para uma chamada do sistema é muito pequena" em alguns terminais, em outros funciona !

Sim Daniel.. São dois problemas bem distintos: 1 - O Fato de estar ocorrendo erro de conexão com a SEFAZ com muita frequencia.. Isso está ocorrendo em todos os clientes, alguns mais, outros menos, porém somente nesse é que a demora para retornar o erro é grande. 2 - Controlar o Time Out do envio. Esse atualmente é o problema que está causando mais dor-de-cabeça, pois o fato da conexão estar lenta ou inativa, não depende de ninguém.. pode acontecer, como está acontecendo. O que está causando a insatisfação do cliente é mesmo esse tempo excessivo para retornar o erro e entrar em contingênica OFF LIne.. Acredito que teria que ter uma forma de abortar esse aguardo em um determinado tempo menor. Eu consegui simular isso aqui em laboratório . Criei um ponto de acesso a internet pelo pacote de dados do meu celular (que é bem básico e lento). Conectado a essa conexão, consegui simular a demora no envio das NFCes. O que me chama a atenção é que se configuro a propriedade SSLLib como libCapicomDelphiSoap recebo o erro: " O tempo limite da operação foi atingido" Recebo essa mensagem de 5 a 20 seg. Configurando a propriedade SSLLib como libOpenSSL recebo o erro: "Erro interno 10060 HTTP:0" ou "erro interno:10090 HTTP:500" Em um tempo que varia de 6 segundos as 30 MINUTOS Tudo isso no mesmo computador, com a mesma conexão de internet etc... Por tudo isso é que acho que deve-se trabalhar uma maneira de abortar o processo em um tempo configurável, ai fica na mão do cliente tornar a conexão dele melhor ou enviar em contingência off line com a mesma conexão ruim,,

Infelizmente o problema de conexão usando libCapicomDelphiSoap ainda acontece, apenas demora sempre 22 seg para retornar o erro enquanto que com libOpenSSL esse tempo varia de 5 a 58 seg. Acredito que não tenho outra saída para resolver essa demora senão usar ThReads, então se alguém puder me ajudar a montar isso eu agradeço pois não sei nem por onde começar ehhhe.

Bom dia Enquanto aguardamos o resultado dos testes hj no cliente gostaria de saber se alguém poderia mandar algum exemplo de como controlar o Time Out do envio/recebimento do retorno da NFCe via THreads. Pelo que vi, essa é a única alternativa para controlar isso.

Boa tarde Só para título de informação... Eu tinha uma cópia do ACBR que estava na minha máquina antes da atualização do dia 02/09/2016. Voltei essa cópia e recompilei os pacotes com o ACBR_Install2.exe e depois recompilei meu aplicativo. Notei que que seu eu alterar a propriedade SSLLib para libCapicomDelphiSoap o problema de falha de conexão ocorre com muito menos frequencia e quando ocorre, a demora no retorno também é bem menor. Se eu utilizar a propriendade SSLlib para libOpenSSL, os erros por falha na conexão ocorrem muito mais frequentemente, e a demora para o retorno é bem maior. Na quarta-feira, vamos acompanhar em mais terminais com essa alteração que fiz para levantar informações desse comportamento.

Será que teria como fazer esse tratamento via Thread no demo para que eu possa ter uma idéia de como implementar isso ?

Me desculpe André.. Estou testando em vários clientes... o problema mais grave é nesse que tem supermercados, mas está ocorrendo em todos.

Entendo, mas no meu caso a situação está caótica.. o Cliente é supermercado, tem várias filiais ocorrendo o problema. Estão ocorrendo filas e reclamações constantes. Vou tentar usar como Capicon, se o problema for conexão de internet, o erro continuará ocorrendo.. Vou eliminar todas as possibilidades.

O que eu acho estranho é a quantidade de notas que da esse problema de conexão depois que da atualização do ACBR... Antes era muito raro ocorrer esse problema, agora ocorre com muita frequencia, mesmo em conexões de internet muito estáveis. Fazendo mais testes aqui, fiquei com a impressão que usando como CAPICON (instalando o certificado A1) esse problema não ocorre. Vou tentar configurar uma filial para usar CAPICON, depois posto o resultado aqui.. Sobre usar Threads, não tenho nenhum conhecimento dessa solução. Acredito que seria o ideal. Não seria possível usar essa solução dentro do próprio componente ?

Bom dia André.. Me perdoe a insistência, mas a pressão no cliente está grande ehehehe Vc conseguiu ver alguma coisa nos logs que postei na sexta feira ?