terça-feira, 27 de maio de 2014

Dois Recursos Interessantes

De vez em quando vivemos momentos explosivos, normalmente aleatórios no tempo, em situações que muitas vezes não sabemos exatamente a causa, e que quando ocorrem a única solução é correr! Muitas vezes nem isso podemos fazer, principalmente porque a solução está em enfrentar o fogo.

Essas situações podem surgir por meio de mensagens indecifráveis que nunca foram vistas por amigos que gentilmente postam soluções, ou pistas, que trazem um pouco de conforto nessas horas. De vez em quando trago algumas dessas situações aqui, no intuito de ajudar pessoas que talvez estejam enfrentando o mesmo leão, ou algum gatinho similar.

Duas situações recentes relacionadas com WebServices fizeram o fogo consumir bastante a minha paciência:

O Dia em que a Terra Parou ou
The remote server returned an error: (404) Not Found . (-10001) 

A primeira foi mais complexa, os webservices simplesmente deixaram de responder.

Não me pergunte o porque ou como ocorreu, simplesmente os webservices que anteriormente se comunicavam naturalmente, deixaram completamente de responder.  O mais interessante é que ao ser chamado o tal programa respondia de forma clara com o WSDL, indicando que o sujeito estava ali esperando alguém. O programa cliente, no entanto, ao se conectar com o bixo enroscava. E uma mensagem de Not Found aparecia.

Essa situação levou semanas para ser corrigida, muita gente foi envolvida para tentar entender a razão. E aproveito para agradecer ao pessoal da Artech (Pablo e Alex) que ajudaram bastante.

E nas tentativas, nessa altura do campeonato movidas pelo desespero, de mexe aqui, acerta ali, a solução surgiu do nada, e veio meio estranha, e também sem explicação plausível, pelo menos para mim, que era a de renomear o webservice.  Incrível, mas ao renomear o tal programa voltou novamente a funcionar.

Não interprete isso como um firewall ou antivírus, que havia bloqueado o tal programa, porque até isso desligamos para tentar resolver a questão, e não resolveu.  Enfim, não sei até agora o porque disso, mas o sistema voltou a funcionar.

Intestino Preso ou
The operation has timed out(-10001)

A segunda apesar de ter sido resolvida de forma mais rápida, foi mais estranha ainda, principalmente porque tinha uma forte relação com os mesmos webservices que deixaram de responder no primeiro caso.  Dai claro, que a principal suspeita foi sobre os tais webservices, e perdemos novamente um tempinho com a mesma abordagem dessa vez com um pouco mais de experiência, renomeia aqui, mexe ali, reprograma.  Enfim, nada de novo, e ainda não funcionando.

O maior problema é que os programas estavam funcionando, porque pararam novamente?  Sempre quando o sistema vai perdendo, ou perde desempenho ao longo do tempo, uma das causas possíveis pode ser o crescimento do banco de dados, pois um índice errado pode causar lentidão entre outras coisas.

Quase por acaso, claro que após algumas horas, ou dias, tentando entender a coisa, finalmente, um select em uma das tabelas manipuladas pelo tal programa revelou uma surpresa. A mesma estava bloqueada:

select * from sis_apptoken

Msg 1205, Level 13, State 52, Line 1
Transaction (Process ID 142) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.


Enfim, uma luz, agora estava claro, o erro não era no webservice e sim no banco, que por alguma razão estava ficando 'preso'. Isso explicava porque no inicio não estava aparecendo problema, porque poucos dias após a tal tabela ter sido programada, agora tinha 20 mil registros.

Um estudo sobre os processos bloqueados mostrou que o Genexus estava incluindo uma operação de UPDLOCK em um select, não sei o porque ainda, creio que temos um bom tema para um próximo artigo.

(@AV11SIS_AppId char(20))SELECT [SIS_AppId], [SIS_AppTokenValid], [SIS_AppToken] FROM [SIS_AppToken] WITH (UPDLOCK) WHERE [SIS_AppId] = @AV11SIS_AppId ORDER BY [SIS_AppId]


E os Dois Recursos Interessantes

Enfim, nem tudo foi perdido, aprendemos alguma coisa, principalmente dois recursos que podem ajudar bastante no desenvolvimento de webservices, e também para entender um pouco situações iguais a esta.

TCPTRACE:
Este programa permite interceptar a comunicação na chamada de um webservice, permitindo visualizar o que está sendo transmitido para o programa e o que está sendo devolvido. Permite que se aprenda com grande facilidade como uma chamada GET ou POST é formada.  Muito útil, principalmente quando se constrói um cliente para um webservice que tenha sido programada em alguma tecnologia não Genexus.

Basta executar o programa e definir uma porta e host de entrada (o qual o cliente deve enviar a solicitação) e a porta e host alvo (onde está de fato o webservice), formando um bypass (desvio). Para que funcione você deve programar uma porta falsa na chamada, ou seja, digamos que o webservice está em localhost na porta 80, seu programa cliente deverá ser programado para apontar para uma outra porta falsa, digamos 8085.  O TCPTRACE, vai interceptar a chamada nesta porta 8085 e redirecionar para a porta real 80.  Um pequeno trabalho, mas uma grande recompensa.

Você pode tentar usar o Wireshark para fazer isso também, é até mais fácil, mas exige um pouco mais de experiência.

Aqui um pouco mais de informação sobre esse recurso:
  • http://www.pocketsoap.com/tcptrace/
  • http://library.gxtechnical.com/gxdlsp/pub/home.htm?/genexus/internet/technicalpapers/debugcallsoap.htm

LOG
Esse aqui é muito interessante e está oculto nas propriedades do Genexus.  Trata-se de uma opção de gravação de LOG disponibilizada pelo próprio Genexus e que possibilita, entre outras coisas, avaliar as ações dos nossos programas em funcionamento.

Para ligar essa opção vá no Enviroment e observe o valor da propriedade Log Level: o valor 6.All faz com que todas as ações sejam gravadas em um arquivo texto, que deve ser criado na raiz da aplicação com o nome client.log
Não se esqueça de desligar isso ao mandar para o sistema para a produção.


Créditos Foto: http://theonlinephotographer.typepad.com/the_online_photographer/2013/07/dont-try-this-at-your-volcano.html