Tratamento de erro na execução de TDFeSendThread

[rhuanrc]

Olá!

Estou usando a configuração TimeOutPorThread (criada na revisão 14797) e estava enfrentando alguns erros de Access Violation em alguns clientes. Analisando verifiquei que o erro estava no método Enviar da classe TDFeSSL, mais especificamente no bloco abaixo:

    EndTime := IncSecond(now,TruncFix(TimeOut/1000));
    SendThread := TDFeSendThread.Create( Self,
                                         TDFeSSLHttpClassOf(FSSLHttpClass.ClassType),
                                         ConteudoXML, AURL, ASoapAction, AMimeType);
    try
      while (SendThread.Response = '') and (Now <= EndTime) do
        Sleep(50);
    finally
      Result := SendThread.Response;
      SendThread.Abort;
    end;

A TDFeSendThread não tinha nenhum tratamento de exceção no Execute e quando ocorriam erros na execução, como um erro de conexão ou sem Internet, a thread era abortada e no finally a variável SendThread já não existia mais, causando o AV. Acontecia esporadicamente e não era muito fácil de simular.

Para corrigir o problema, implementei um tratamento de exceção no Execute da thread e tratei para abortar o while de verificação caso algum erro ocorra. Também alterei para que a thread fosse liberada manualmente ao final do envio.

Peço que analisem e subam para o SVN se possível.

ACBrDFeSSL.pas

[BigWings]

Em 18/10/2018 at 07:24, rhuanrc disse:

ACBrDFeSSL.pas

Esse arquivo é idêntico ao do repositório.

[rhuanrc]

Desculpa, anexei o arquivo errado. Segue novamente.

ACBrDFeSSL.pas

[Daniel Simoes]

Desculpe-me pela demora na resposta...

Verifiquei a sua sugestão, e realmente faltou um tratamento interno para a Thread, capturar os Exceptions.. O Exception disparado abortava o código da Thread, que já era liberada pelo FreeOnTerminate, por isso tínhamos o A.V.

Essa Thread tem uma característica diferente das Threads tradicionais... A ideia é deixar que ela mesmo se libere... Isso porque lidar com Socktes, pode prender o sistema, mesmo quando configuramos os TimOuts na API.. então não podemos ficar esperando o final normal da Thread...

Fiz alguns ajustes, baseado nas suas sugestões...

Por favor teste com a Unit em anexo... Também fiz algumas melhorias, para o caso abaixo:

 

ACBrDFeSSL.pas

[rhuanrc]

Fiz testes usando a unit que você alterou e voltou a acontecer o A.V. Consegui simular da seguinte forma:

- Adicionei um "raise exception" dentro do Execute da thread apenas para forçar um erro qualquer.

- Fiz o envio de algumas notas em sequência.

Em algumas notas ocorreu o A.V. no finally do código que pega as informações da thread após finalizá-la, conforme o comentário que coloquei abaixo:

Citar

   try
      while (not SendThread.Done) and (Now <= EndTime) do
        Sleep(50);
    finally

      // O A.V. ocorreu nas linhas abaixo. O objeto SendThread foi liberado da memória antes de conseguir capturar as mensagens.
      Result := SendThread.Response; 
      ErrorMsg := SendThread.ExceptMessage;

      SendThread.Abort; // Isso forçará a Thread terminar, e morrer por si...
    end;

Parece-me que após Abortar a thread no tratamento de exceção e antes de capturar as mensagens de Response e ExceptMessage a thread está sendo liberada. Esse problema não aconteceu em todas as notas que tentei enviar.

[Daniel Simoes]

Uma nova tentativa... por favor teste com a Unit em anexo...

Nessa nova modificação, ligo o FreeOnTerminate, apenas quando a Thread atingiu o timeout... assim não ficamos presos no "Thread.waitfor", quando aplicarmos o Abort.

 

ACBrDFeSSL.pas

[rhuanrc]

Muito bom! Funcionou perfeitamente. Na minha primeira tentativa tinha desabilitado o FreeOnTerminate, mas sua implementação ficou melhor e mais limpa.

Quando quiserem podem subir o fonte ao SVN. Obrigado pela atenção, Daniel! 

[Juliana Tamizou]

Bom dia.

Alteração no svn, tópico será encerrado.

Att.a sim