Árvore de páginas
Ir para o final dos metadados
Ir para o início dos metadados
 Configuração padrão do broker

O broker deve funcionar normalmente apenas com a configuração mínima do arquivo de configuração (arquivo .ini).

Por exemplo:

[BALANCE_SMART_CLIENT_DESKTOP]

; nome do serviço Windows (apenas se broker for usado como serviço Windows)
SERVICE_NAME = Nome_Serviço_Windows

; porta TCP onde os cliente se conectam
LOCAL_SERVER_PORT = 5000

; servidores para serem balanceados
REMOTE_SERVER_01 = 127.0.0.1 6001
REMOTE_SERVER_02 = 127.0.0.1 6002
; etc

Se qualquer outra configuração adicional for utilizada no arquivo .ini, recomenda-se fortemente que seja documentado em comentários o motivo da inclusão desta configuração adicional, para facilitar o processo de suporte e manutenção do broker.

No exemplo abaixo alteramos o tempo de standby do broker (tempo que o broker segura a, quando a  conexão com um smartclient é perdida).

Incluímos uma nova configuração, então colocamos uma explicação porque esta configuração foi incluída.

[BALANCE_SMART_CLIENT_DESKTOP]

; nome do serviço Windows (apenas se broker for usado como serviço Windows)
SERVICE_NAME = Nome_Serviço_Windows

; porta TCP onde os cliente se conectam
LOCAL_SERVER_PORT = 5000

; servidores para serem balanceados
REMOTE_SERVER_01 = 127.0.0.1 6001
REMOTE_SERVER_02 = 127.0.0.1 6002
; etc

; aumentado o tempo de espera de reconexão do smartclient para compatibilizar
; com a configuração do application server
; atenção: manter sempre sincronizado com a configuração do application server
STANDBY_TIME = 200

Obs. as observações acima não aplicam à configuração do log. que deve estar sempre ativo para o broker.
Exemplo:
[General]
   ConsoleLog = 1
   ConsoleFile = ...
   ConsoleMaxSize = ...
   ; etc

 Erros de web services com broker em servidores Protheus

O broker é comumente utilizado para balancear consumo de web services fornecidos por servidores Protheus.

O broker utilizado é o "broker de web services" (no ini existe a chave "[BALANCE_WEB_SERVICES]").

Neste cenário, um pré-requisito para o funcionamento correto é que a aplicação cliente NÃO deve utilize conexões HTTP persistentes (header HTTP "Connection: Keep-Alive").

Esta é uma característica do servidor Protheus, que fecha a conexão logo em seguida ao envio da resposta de um pedido de web services.

Caso a aplicação cliente utiliza conexões persistentes no log do broker eventualmente pode aparecer a mensagem

       "late reception from client in state WAITING_CLIENT_CLOSE, there are no more  pending operations".

Em versões mais antigas do broker a mensagem está em português:

     "recepcao atrasada do cliente em WAITING_CLIENT_CLOSE, nao existem mais operacoes pendentes".

Portanto, na eventualidade de ocorrer erros intermitentes na utilização do broker de web services para balanceamento de web services para servidores Protheus, verificar o log do broker,

e se no log do broker aparecer uma das mensagens acima, configurar a aplicação cliente para utilizar conexões nao-persistentes (header HTTP "Connection: close").

Notar que o modo padrão da conexão na especificação HTTP 1.1 é "conexão persistente", isto é, quando a aplicação cliente não envia o header "Connection:", subentende-se que é como se tenha enviado o header "Connection: Keep-Alive". Portanto, a aplicação cliente deve ser configurada para enviar explicitamente o header "Connection: close".

É importante entender que esta situação de erro não é causada pelo broker. Mesmo sem a utilização do broker podem ocorrer erros, quando a aplicação cliente tentar enviar um segundo pedido de web services em uma conexão que já foi fechada pelo Protheus. A utilização do broker (ou qualquer outro proxy de balanceamento) no entanto pode potencializar a ocorrência desses erros, por causa do retardo (lag) adicional associado ao processo de balanceamento.


 Detalhes do balanceamento de smart client HTML com broker HTTP

Browser

Todas as abas de um mesmo browser vão para o mesmo slave, porque o broker usa um cookie no browser para amarrar o browser com o slave.

Ao abrir um Chrome e um Firefox e utilizar o mesmo broker para ambos, todas as conexões de smart client HTML (via broker) do Chrome irão para o mesmo slave, e todas as conexões de smart client HTML (via broker) do Firefox irão para o mesmo slave, que pode ser diferente do slave que atende o Chrome.

O browser tem um limite de abas (normalmente 6) que ele pode abrir ao mesmo para uma url, no caso a url do broker ou de um slave.
Então um browser pode ter no máximo 6 abas abertas com o mesmo broker.

Broker - balanceamento pode ser por número de sessões, ou por método round robin.

Broker - Sessões (Conexões no Protheus)


O broker vai distribuir os smart clients pelos slaves, sempre mandando para o slave com menos conexões.

O broker não faz distinção por máquina física, mas pelo endpoint: (ip/nome + porta).

Se no ini do broker os slaves forem agrupados por máquina física, então inicialmente o broker vai distribuir as conexões pelos slaves da primeira máquina física, depois pela segunda máquina física, etc.

O que se pode fazer é deixar intercalados no ini os slaves de máquinas físicas diferentes, assim no início o broker vai distribuir as conexões por máquinas diferentes.
Exemplo:
     REMOTE_SERVER_01 = maquina1 porta1
     REMOTE_SERVER_02 = maquina2 porta1
     REMOTE_SERVER_03 = maquina3 porta1
     REMOTE_SERVER_04 = maquina1 porta2
     REMOTE_SERVER_05 = maquina2 porta2
     REMOTE_SERVER_06 = maquina3 porta2
     REMOTE_SERVER_07 = maquina1 porta1
     REMOTE_SERVER_08 = maquina2 porta2
     REMOTE_SERVER_08 = maquina3 porta3

Broker - Round Robin

Colocar no ini do broker:
   SORT_METHOD = ROUND_ROBIN 

O broker vai distribuir os smart clients pelos slaves, seguindo a ordem que aparecem no ini do broker, sem fazer contagem de sessões/conexões.

O broker não faz distinção por máquina física, mas pelo endpoint (ip + port).

Se no ini do broker os slaves forem agrupados por máquina física, então sempre o broker vai distribuir as conexões pelos slaves da primeira máquina física, depois pela segunda máquina física, etc!

O que se pode fazer é deixar intercalados no ini os slaves de máquinas físicas diferentes, assim sempre o broker vai distribuir as conexões por máquinas diferentes.
Exemplo:
     REMOTE_SERVER_01 = maquina1 porta1
     REMOTE_SERVER_02 = maquina2 porta1
     REMOTE_SERVER_03 = maquina3 porta1
     REMOTE_SERVER_04 = maquina1 porta2
     REMOTE_SERVER_05 = maquina2 porta2
     REMOTE_SERVER_06 = maquina3 porta2
     REMOTE_SERVER_07 = maquina1 porta1
     REMOTE_SERVER_08 = maquina2 porta2
     REMOTE_SERVER_08 = maquina3 porta3

OBSERVAÇÃO: o método de balanceamento round robin é muito pouco usado em campo, então antes de ser usado sugere-se que seja feita uma homologação antes de ser colocado em produção.


Log do broker

No log do broker é fácil de ver o processo de balanceamento.

Smart client que não está na tabela do broker:
180322_111802 313C SHC0146 W x 01 ctx:008 o0r0R0s0S0 key CFC2D4ADDE2516488B46835DEBC0D345 not associated with a server // c:127.0.0.1:16722
180322_111802 313C BAL1111 N ctx:8 found available server 127.0.0.1:50004 association count:0
180322_111802 313C BAL0850 N associating key CFC2D4ADDE2516488B46835DEBC0D345 to server 127.0.0.1:50004 q0 (nAssoc: 0->1) (cli: 127.0.0.1:16722)

Smart client que já está na tabela do broker:
180322_111803 313C SHC0131 N x 01 ctx:009 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16724
180322_111803 313C SHC0131 N x 01 ctx:007 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16725
180322_111803 313C SHC0131 N x 01 ctx:011 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16727
180322_111803 313C SHC0131 N x 01 ctx:010 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16728

outro smart client que não está na tabela do broker:
180322_111810 313C SHC0146 W x 01 ctx:014 o0r0R0s0S0 key F3D0B8F106035D4CB48D4BB973F849AA not associated with a server // c:127.0.0.1:16733
180322_111810 313C BAL1111 N ctx:14 found available server 127.0.0.1:50003 association count:0
180322_111810 313C BAL0850 N associating key F3D0B8F106035D4CB48D4BB973F849AA to server 127.0.0.1:50003 q0 (nAssoc: 0->1) (cli: 127.0.0.1:16733)

etc


 Nome do serviço broker no Windows

O nome do serviço broker no Windows é especificado pela chave SERVICE_NAME no arquivo de configuração appserver.ini do broker.

A partir da versão 2.1.2 do broker (TOTVS - Build 7.00.131227A - Jan 23 2018 - 15:25:33 NG) também é possível especificar o "display name" do serviço Windows, através da chave SERVICE_DISPLAY_NAME, inclusive com a utilização de espaços e caracteres especiais (neste caso, o "display name" deve estar entre aspas).

Observação: nesta versão 2.1.2 quando utilizando broker http e não for especificado o "display name" no arquivo de configuração, será utilizado o nome padrão TOTVS_BROKER_SH. como "display name" do serviço. Numa próxima versão será alterado este comportamento, para que se o "display name" não for especificado então seja utilizado o mesmo valor do "service name".

É possível mudar o "display name" de qualquer serviço (inclusive o broker) através de comandos na console do Windows.

Por exemplo, supondo a seguinte configuração do broker


    [BALANCE_HTTP]
    SERVICE_NAME = AAA
    SERVICE_DISPLAY_NAME = "Serviço sem nome"


podemos  alterar o "display name" deste serviço na console (com direitos administrativos) do Windows com o seguinte comando:
    sc config AAA DisplayName="Broker - Cliente 123"


Após isso, na janela de serviços do Windows vai aparecer o nome "Broker - Cliente 123" referente ao serviço AAA.


Obs. a partir da versão 2.1.3 (embarcada no binário do P12 13.2.3.29) esta situação está resolvida: caso não seja fornecida a chave SERVICE_DISPLAY_NAME, o "display name" do serviço broker será o nome usado na chave SERVICE_NAME.

 Não conecta no WebService com o Broker

Verifique se a sua configuração no .ini do AppServer contém as referências para o Servidor do Broker.

Ex. Cheque se o IP e a porta do Broker Server estão configurados como Serviço no appserver.ini

[maquinadobroker:32081/ws]

RESPONSEJOB=JOB_WS
DEFAULTPAGE=wsindex.apw
PATH=\protheus12\protheus_data\webservices\web

Mais informações em veja em Balanceamento de carga com Broker, seção "Balanceamento entre cliente Web Services"


 Não conecta no Portal (HTTP) com o Broker

Verifique se a sua configuração no .ini do AppServer contém as referências para o Servidor do Broker.

Ex. Se o portal usar Web Services, cheque se o IP e a porta do Broker Server estão configurados como Serviço no appserver.ini

[maquinadobroker:32081/ws]

RESPONSEJOB=JOB_WS
DEFAULTPAGE=wsindex.apw
PATH=\protheus12\protheus_data\webservices\web

Mais informações em veja em Balanceamento de carga com Broker, seção "Balanceamento entre Clientes HTML e servidor Protheus"


 Sessão do Portal expira

Verifique se a sua configuração no .ini do Broker está com os valores de expiração de sessão com um valor apropriado.

Ex.

[BALANCE_HTML]
; porta que atende o Client HTML
LOCAL_SERVER_PORT = 4000
REMOTE_SERVER_01 = 172.16.106.31 5001
 
; tempo de retencao de uma sessao inativa, em segundos
SESSION_TIMEOUT = 600

Mais informações em veja em Balanceamento de carga com Broker, seção "Balanceamento entre Clientes HTML e servidor Protheus"


 Tempo de inatividade do smartclient html quando usado com broker http

A opção SESSION_TIMEOUT no arquivo de configuração appserver.ini do broker HTTP não se aplica ao smartclient HTML.

Quando o SmartClient HTML é utilizado com o broker HTTP, o controle de tempo de inatividade continua sendo feito normalmente pelo Protheus através da chave InactiveTImeout no arquivo de configuração appserver.ini do Protheus (http://tdn.totvs.com/x/e4pc).

Mesmo sem atividade do usuário internamente o smartclient HTML envia mensagens de comunicação para o server Protheus  uma vez a cada 60 segundos. Portanto, não se deve incluir a chave SESSION_TIMEOUT na configuração do broker Protheus quando utilizado com smartclient HTML.

 Smartclient não conecta com broker
  1. Se o smartclient não se conecta com o servidor Protheus via broker, e a versão do smartclient está entre  31/03/2016 e 20/08/2016,abrir chamado e solicitar uma nova versão do smartclient. Essas versões possuem instabilidade conhecida quando utilizadas com broker. (Para obter a versão, executar na numa janela DOS a linha de comando "smartclient.exe -T" .)
  2. Verificar se o serviço broker no Windows foi instalado corretamente, e especialmente verificar que o nome do serviço broker do Windows não pode conter espaços
 Falha de conexão com o Broker

Se a conexão com o Broker já funcionava e passou a apresentar problemas, providencie os seguintes artefatos:

  • todos os arquivos de logs do Broker Server no servidor

Ex. console.* ou arquivo da sessão [General] -> ConsoleFile=c:\broker\console.log

Caso seja Balance de SmartClient:

    • todos os arquivos de logs do Broker Client no SmartClient

Ex. tbc*.txt
 

  • obter os arquivos de logs dos AppServer com problema

Ex. console.* ou arquivo da sessão [General] -> ConsoleFile=c:\protheus\console.log
 

  • informar a data e hora da ocorrência
     
  • obter o arquivo de configuração do Broker Server

Ex. broker.ini ou appserver.ini
 

  • obter a versão do Broker Server

Ex. broker.exe -balance_smart_client_desktop

*
* TOTVS - Build 7.00.131227A - Jul 25 2016 - 13:26:11 NG
* Build: 32 bits
* SVN Revision: 8685 - 11390 - 1508
*
* Protheus Balance Server para Smart Client Desktop
* Copyright 2013-2016 Totvs S.A.
* www.totvs.com.br
*
 

  • obter o arquivo de configuração dos AppServer com problema

Ex. appserver.ini
 

Caso seja Balance de SmartClient

    • obter o arquivo de configuração do SmartClient da estação com problema
      Ex. smartclient.ini
    • informar descrição/imagem dos parâmetros de execução do SmartClient e a descrição/imagem do erro em tela

Caso seja Balance de WebService ou Balance de HTTP

Quando o Broker estiver rodando como Serviço:

    • obter os logs do sistema operacinal
      Ex.
      - no windows:
      logs do "Event Viewer"
      - no Linux:
      /var/log/messages
       
  • informar a versão do SO Broker e dos Clientes (quando for SmartClient)
     
  • informar se o Broker Server está rodando na mesma máquina dos AppServer
     
  • obter as configurações de rede das estações do servidor do Broker e dos clientes

Ex.
- no windows:
ipconfig /all

- no Linux:
ifconfig -a
 

  • obter as configurações das portas da estação do servidor

Ex.
- no windows:
netstat -an -p tcp | findstr /i listening
netstat -anb -p tcp

- no Linux:
netstat -antp | grep -i listen
ps -aux 
 

Obs. Se estação que apresentou problemas de conexão com o Broker não for via o SmartClient Desktop, não haverá logs ou arquivos de configuração do Broker nestas estações.
 

 Broker nunca conectou ou não conecta mais

Se a conexão com o Broker não conecta, execute os seguintes passos e providencie os artefatos:

  • Desative o Broker Server faça um telnet na sua porta e verifique que não está conectando na porta.

Ex. telnet 132.7.45.120 8090

Se a conexão estiver fechando verifique quais serviços na máquina estão ativos, erradamente, respondendo na porta do Broker Server (veja em: obter as configurações das portas da estação do servidor)
 

  • Ative o Broker Server faça um telnet na sua porta e verifique se está conectando na porta.

Ex. telnet 132.7.45.120 8090

Se a conexão não estiver fechando verifique a infra estrutura de rede (cabos, firewall, antivírus, configurações de IP e porta, ...)
 

  • Faça testes desativando possíveis Firewall e antivírus que possam estar bloqueando a porta do Broker Server
     
  • Teste para validar a conexão local,faça teste de conexão na mesma máquina onde está o Broker Server (com SmartClient, com telnet, WebService ou Browser), caso funcione verifique as suas configurações de rede, firewall e antivírus com o administrador.
     

Caso não seja identificado o problema:

    • providencie todos os artefatos da sessão "Falha de conexão com o Broker"


 Estou com problemas e eu uso o totvs_broker_sg ou totvs_broker_sh, o que devo fazer?

Esta versão utilizada do Broker é uma versão descontinuada e deve ser atualizada para a versão corrente.


Para atualizar a versão seguir as instruções contidas em:
http://tdn.totvs.com/pages/viewpage.action?pageId=213979358
 

 Uso de broker para smart client (desktop) com SSL

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

 

 Uso do broker HTTP com SSL

O broker HTTP pode ser usado como para receber conexões SSL vindas do cliente, e abrir conexões não-SSL com o servidor (appserver).

É importante ter em mente que não é possível garantir o funcionamento do broker com toda e qualquer aplicação web que use conexões criptografadas com o browser, por causa da enorme variedade de técnicas que podem ser utilizadas para escrever aplicações web.

Em outras palavras, antes de fazer o deployment de uma solução web neste cenário é preciso que a solução seja validada em laboratório com o broker configurado para aceitar conexões SSL.

Um outro ponto a considerar é que a solução precisa ser validada com browsers específicos (p. ex: Chrome e Firefox) devido ao fato de que diferentes browsers apresentam diferentes comportamentos, dependendo dos recursos utilizados ao escrever a aplicação web.


A configuração do broker para receber conexões SSL necessita das seguintes chaves no arquivo de configuração appserver.ini:

...
...
SSL_METHOD=SSL/TLS
SSL_CERTIFICATE=<nome do arquivo que contem o certificado>
SSL_KEY=<nome do arquivo que contem a chave a chave privada>
SSL_PASSPHRASE=<senha de proteção da chave privada>

; opcional
USING_SECURE_COOKIES = 1
...
...

A chave SSL_METHOD=SSL/TLS indica que o broker vai aceitar qualquer método escolhido pelo cliente.
A chave USING_SECURE_COOKIES indica ao broker se o cookie de sessão do broker vai ser criado como "secure cookie" (com atributos "secure" e "HttpOnly").


 Erros de infra-estrutura

Existem certos erros gerados pelo sistema operacional que impactam a operação do broker. Quando estes erros aparecem nos logs do broker eles se referem a problemas de infra-estrutra (hardware, rede, bugs do sistema operacional, etc), e portanto não são causados pelo broker.


Erro 121:

Nos logs do broker aparece como "status 121 (expirou timeout da operacao)".

No site da Microsoft a descrição do erro é: "ERROR_SEM_TIMEOUT 121 (0x79) the semaphore timeout period has expired.


Erro 10050:

Nos logs do broker aparece como "status 10050 (a socket operation encountered a dead network)".

No site da  Microsoft a descrição do erro é: "Network is down. A socket operation encountered a dead network. This could indicate a serious failure of the network system (that is, the protocol stack that the Windows Sockets DLL runs over), the network interface, or the local network itself."


Erro 10051:

Nos logs do broker pode aparecer como "erro 10051" ou "network is unreachable"..

É um erro retornado pelo Windows quando não existe rota entre uma aplicação e o host a que esta aplicação está se tentando conectar. Pode ser erro na configuração na lista de slaves do broker, ou pode realmente ser um erro de infra-estrutura.


Erro 10065: idem erro 10051, mas a mensagem correspondente é "no route to host".


Á medida que outros erros semelhantes forem encontrados eles serão adicionados a esta lista.


 Erros operacionais ou de configuração

Existem certos erros que se referem à configuração ou à operação do ambiente e que impactam a operação do broker. Quando estes erros aparecem nos logs do broker eles indicam que é necessário alguma ação corretiva da equipe de operação. Normalmente o broker grava um evento no log do Windows quando ocorre esses erros.


Erro 1225:

Nos logs do broker pode aparecer como "erro 1225" ou "connection refused"..

É um erro retornado pelo Windows quando uma aplicação server tenta se conectar a uma porta TCP, mas não existe nenhuma aplicação atendendo naquela porta. Por exemplo, o broker tenta se conectar com um slave, mas não existe nenhuma slave atendendo na porta que o broker tentou se conectar.  A causa pode ser erro de configuração no broker (configuração errada se slaves), ou então realmente o slave estava fora do ar quando o broker tentou se conectar.


Erro 10048:

Nos logs do broker pode aparecer como "erro 10048" ou "address already in use"..

É um erro retornado pelo Windows quando uma aplicação server tenta usar uma porta TCP que já está em uso por outra operação server. A ação a ser tomada neste caso é descobrir qual é a outra operação que está usando a porta. Pode acontecer mais raramente quando ocorre crash da aplicação, ou quando a aplicação é terminada de maneira forçada no task manager do Windows. Este erro pode aparecer na inicialização do broker.


Erro 10051:

Nos logs do broker pode aparecer como "erro 10051" ou "network is unreachable"..

É um erro retornado pelo Windows quando não existe rota entre uma aplicação e o host a que esta aplicação está se tentando conectar. Pode ser erro na configuração na lista de slaves do broker, ou pode realmente ser um erro de infra-estrutura.


Erro 10061: idem erro 1225.


Erro 10065: idem erro 10051, mas a mensagem correspondente é "no route to host".


À medida que outros erros semelhantes forem encontrados eles serão adicionados a esta lista.


 Log de conexão bem sucedida (smart client desktop)

 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.

 Log de conexão: erro na configuração do ip do broker no smartclient.ini (smart client desktop)
Neste exemplo foi configurado no smartclient.ini o broker com ip 123.123.123.123. A DLL tenta se conectar com esse ip mas não recebe resposta, e por volta de 23 segundos depois o Windows retorna erro 121. A DLL fecha conexão com o smart client, que então mostra a tela de erro de conexão. (O que provavelmente aconteceu foi o pedido de conexão ter saído da rede corporativa para a internet, onde foi descartado por algum roteador ou servidor. PS. este é um ip da China, na área de Pequim).


 Log de conexão: erro na configuração da porta do broker no smartclient.ini (smart client desktop)
Neste exemplo foi configurado no smartclient.ini o broker com porta na 8002 na máquina local (127.0.0.1), mas não existe nenhum broker atendendo nesta porta. A DLL tenta se conectar com o broker em 127.0.0.1:8002, mas imediatamente o Windows responde com  erro 1225. A DLL fecha conexão com o smart client, que então mostra a tela de erro de conexão.
 Utilização de mais de 99 servidores balanceados

Para utilizar mais de 99 servidores balanceados utilizar letras (A-Z) para compor a chave REMOTE_SERVER_xx, pois esta chave só pode conter 2 caracteres de identificação.

Por exemplo:

REMOTE_SERVER_98 = 10.58.243.149 12098 10

REMOTE_SERVER_99 = 10.58.243.149 12099 10

REMOTE_SERVER_AA = 10.58.243.149 12100 10

REMOTE_SERVER_AB = 10.58.243.149 12101 10

REMOTE_SERVER_AC = 10.58.243.149 12102 10


Qualquer combinação de letras e números (2 caracteres) é aceita.

 Consulta do status do broker com Chrome, Firefox, etc

Os brokers para smart client e HTTP fornecem uma interface de consulta via navegador web (Chrome, Firefox, etc). Através dessa interface é possível verificar se o broker está em execução, e visualizar algumas informa ções sobre a execução atual do broker, tais como versão, hora de início, número de conexões, etc.

O acesso à interface web do broker se dá através da URL base http://ip:porta/TOTVS_BROKER_QUERY. Os comandos que podem ser usados através desta url são STATUS, CFG, e PING.

Telas do broker HTTP: tela de STATUS, tela de configuração  CFG e tela de PING.


 Monioramento dos servidores remotos

Uma vez por minuto os broker smart client, http e web services tentam se comunicar com os servidores remotos configurado. Os servidores que não respondem são colocados em "quarentena" por 2 minutos, isto é, o broker não redireciona novos pedidos de conexão para esses servidores por 2 minutos. Os servidores que respondem ao broker e estavam de quarentena são retirados da quarentena.

As informações sobre o monitoramento são também registradas no arquivo console.log do broker.

Exemplo com 4 servidores configurados.

Se todos responderam ao monitoramento:

                "monitor: OK - 4 servers available, 0 servers unavailable  "

Se apenas 3 servidores  responderam ao monitoramento:

                " * erro: 1225 tipo mensagem: 2 na conexao com o server [myPort=0 server=127.0.0.1:5003]"

                "colocando servidor 127.0.0.1:5003 em quarentena  start=1518696862 stop=1518696982 (monitor)"

                "monitor: OK - 3 servers available, 1 server unavailable"

                "monitor: server 127.0.0.1:5003 unavailable  "

Se nenhum servidor respondeu ao monitoramento:

                " * erro: 1225 tipo mensagem: 2 na conexao com o server [myPort=0 server=127.0.0.1:5003]"

                "* erro: 1225 tipo mensagem: 2 na conexao com o server [myPort=0 server=127.0.0.1:5004]"

                "* erro: 1225 tipo mensagem: 2 na conexao com o server [myPort=0 server=127.0.0.1:5001]"

                "colocando servidor 127.0.0.1:5003 em quarentena  start=1518697390 stop=1518697510 (monitor)"

                "colocando servidor 127.0.0.1:5004 em quarentena  start=1518697390 stop=1518697510 (monitor)"

                "* erro: 1225 tipo mensagem: 2 na conexao com o server [myPort=0 server=127.0.0.1:5002]"

                "colocando servidor 127.0.0.1:5001 em quarentena  start=1518697390 stop=1518697510 (monitor)"

                "colocando servidor 127.0.0.1:5002 em quarentena  start=1518697390 stop=1518697510 (monitor)"

                "monitor: OK - 0 servers available, 4 servers unavailable"

                "monitor: attention, there are no remote servers available "

A tela de consulta de status do broker (ver item anterior) também mostra os servidores que estão em quarentena.




  • Sem rótulos