Histórico da Página

Quando ocorre uma interrupção da conexão de rede e o smart client inicia o processo de recuperação de conexão, a dll do broker faz (por padrão) no máximo 12 tentativas de reconexão. No entanto este processo também depende de como o application server está configurado.

Por padrão (isto é, sem configuração adicional) o application server encerra a thread  do usuário caso a rede fique inativa por 180 segundos (3 minutos). Portanto, se o processo de recuperação do smart client demorar mais do que 3 minutos, quando o smart client conseguir se reconectar com o broker a recuperação da conexão com o application server não será mais possível, pois a conexão do broker com o application server não existe mais (o application server encerrou a thread do usuário e fechou a conexão comn o broker).

Para aumentar o tempo que o application server espera antes de encerrar a thread do usuário existe a chave ConnectionTimeout no arquivo de configuração appserver.ini do application server. (Esta chave pode ser especificada no environment ou na seção General). Por exemplo, no caso abaixo

[Enviroment_X]
...
...
...
ConnectionTimeout = 300
...
...
...

o application server vai esperar 5 minutos antes de terminar a thread do usuário conectado neste environment, portanto vai ser possível a recuperação da conexão do smart client com o application server mesmo que a rede demore 5 minutos para voltar.

Obs. caso exista um problema na infra-estrutura local do smartclient (p. ex: cabo de rede desconectado, cabo de rede com defeito, problema no switch ao qual o smartclient está conectado, etc) o tempo máximo de reconexão é de 1 minuto.

Página referente à chave ConnectionTimeout no TDN: http://tdn.totvs.com/x/dopc.

...
...
[SSLConfigure]
CertificateClient=<nome do arquivo .pem>
KeyClient=<nome dp arquivo .pem>
PassPhrase=password
...
...
; 172.16.70.96:20001 são o ip e porta do broker
[conexao_ssl_broker]
server=172.16.70.96
port=20001
SecureConnection=1
...
...

...
...
LOCAL_SERVER_PORT = 20001
...
; 172.16.70.96:50001 são o ip e porta do appserver
REMOTE_SERVER_01 = 172.16.70.96 50001
...
...
MONITORING_TYPE = SMARTCLIENT_SSL 

...
...
[drivers]
ACTIVE = TCP
SECURE = SSL
...
...
[TCP]
type=TCPIP
port=...
...
[SSL]
type=TCPIP
port=50001
...
...
[SSLConfigure]
CertificateServer=<nome do arquivo .pem>
KeyServer=<nome do arquivo .pem>
...
...

 Numa conexão bem sucedida do smart client desktop com o appserver via broker temos 3 arquivos de log envolvidos: log da DLL do broker, log do broker, e log do appserver.

Log da DLL do broker

Este log mostra várias informações úteis, como a versão da DLL, o host onde o smart client está rodando, ip e porta do broker, id do handshale, e hora de início e finalização da conexão.

Neste exemplo, temos que:

   versão da DLL: 2.0.16

   host onde está rodando o smart client: tec-***** (ip 10.172.78.66)

   ip e porta do broker: 127.0.0.1:50000

   id do handshake: AEF50...52F4F9 (utilizado para rastrear a conexão no log do broker)

   hora de início da conexão: 14:43:34

   hora de finalização da conexão: 14:45:26

O importante neste exemplo é notar que como a conexão aconteceu sem erros, aparece a linha com a mensagem "sucesso na criação de nova conexão", e depois de um certo tempo (tempo que o usuário operou o smart client) aparece a linha com a mensagem "conexão cliente fechada remotamente", após o usuário ter fechado o smart client de maneira normal.

Log do broker

No log do broker correspondente também temos várias informações úteis, mas o interessante neste exemplo são as sequências de inicialização e finalização da conexão do smart client.

Podemos ver na linha com a mensagem ""recebeu handshake inicial do cliente" o mesmo id AEF50...52F4F9 que aparece no log da DLL. Esta linha mostra uma outra informação importante: o "contexto" associado a esta conexão: ctx:008. Todas as mensagens no log referentes a esta conexão vão estar associadas a este contexto "ctx:008". Desta maneira, podemos isolar as mensagens referentes a conexões específicas, mesmo que muitos smart clients utilizem o mesmo broker.

A sequência de inicialização de uma conexão bem sucedida começa com a mensagem "recebeu handshake inicial" e vai até a linha "sucesso na criação de nova conexão". A partir deste ponto o smart client está conversando normalmente com o appserver (vai aparecer no monitor do server).

A sequência de finalização normal começa com a linha "conexão cliente fechada remotamente" (isto é, o smart client fechou a conexão) e vai até a linha "erro, conxão fechada pelo servidor em modo standby". O motivo desta linha de "erro" é que o broker não sabe que a conexão está sendo fechada normalmente. Por causa disso quando o smart client fecha a conexão o broker deixa a conexão em standby, mas logo em seguida o appserver fecha a conexão (o que é normal), causando esta mensagem de "erro" no log do broker.

Notar que neste exemplo de teste havia apenas um smart client sendo usado, então todas as linhas referentes a este smart client apareceram em sequência no log do broker. Num cenário normal com muitos smart clients as mensagens referentes aos vários smart clients aparecem misturadas.

Log o appserver

O log do appserver referente a esta conexão mostra o início e o final, sem outras informações adicionais porque o teste consistiu apenas de algumas trocas de telas. Notar novamente que, como havia apenas um único smart client conectado, as mensagens de início e final da conexão aparecem em sequência, uma logo em seguida da outra.

É interessante observar as marcações de tempo nos 3 logs. No log da DLL o início efetivo da conexão foi às 14:43:34, no log do broker também às 14:43:34, e no log do appserver às 14:43:37. O fechamento aparece no log do appserver às 14:45:26, no log do broker às 14:45:26, e no log da DLL também às 14:45:26.