- Criado por Jose Vitor De Santana, última alteração em 30 ago, 2018
Você está vendo a versão antiga da página. Ver a versão atual.
Comparar com o atual Ver Histórico da Página
« Anterior Versão 4 Próxima »
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.
O broker usado com smart client (desktop) é "agnóstico" com relação a conexões criptografadas. Isto é, conxões criptografadas podem ser usadas normalmente desde que o appserver e o smart client estejam configurados corretamente, conforme especificado na página Configuração SSL no TOTVS | Application Server. (O broker funciona como um "proxy transparente".)
O arquivo smartclient.ini vai precisar da seção [SSLConfigure], e na especificação da conexão com o broker vai ser necessária a chave SecureConnection.
Exemplo de smartclient.ini para uso com broker e conexão segura:
... ... [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 ... ...
A configuração do arquivo appserver.ini do broker ficaria assim:
... ... 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
E a configuração do arquivo appserver.ini do appserver ficaria assim:
... ... [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.
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.
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.
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.
- Sem rótulos