Home

TOTVS Technology

Child pages
  • FAQ - Frequently Asked Questions.
Skip to end of metadata
Go to start of metadata
 No connection to WebService with the Broker

Check whether your settings on the AppServer .ini reference the Broker Server.

Example: Check whether the Broker Server IP and port are set to Service in appserver.ini

[maquinadobroker:32081/ws]

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

Further information in Broker Load Balancing, section "Balancing between Web Services client"

 No connection to Portal (HTTP) with the Broker

Check whether your settings on the AppServer .ini reference the Broker Server.

Example: If the portal uses Web Services, check whether the Broker Server IP and port are set to Service in appserver.ini

[brokercomputer:32081/ws]

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

Further information in Broker Load Balancing, section "Balancing between HTML and Protheus server clients"

 Portal Session expires

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"


 Smartclient does not connect with broker
  1. If SmartClient does not connect with the Protheus server via broker, and the SmartClient version is between 3/31/2016 and 8/20/2016, open a ticket and request a new SmartClient version. These versions have a known instability when used with broker. To get the version, execute the command line "smartclient.exe -T" in a DOS window).
  2. Check whether the broker service in Windows was correctly installed, and especially make sure the name of the Windows broker service has no spaces
 Connection failure with Broker

If the connection with the Broker was working but presented problems, provide the following artifacts:

  • all Broker Server log files in server

Example: console.* or file of session [General] -> ConsoleFile=c:\broker\console.log

If Balance of SmartClient:

    • all Broker Client log files in SmartClient

Example: tbc*.txt
 

  • get AppServer log files with problems

Example: console.* or file of session [General] -> ConsoleFile=c:\protheus\console.log
 

  • enter date and time of occurrence
     
  • get the Broker Server settings file

Example: broker.ini or appserver.ini
 

  • get Broker Server version

Example: 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 for Smart Client Desktop
* Copyright 2013-2016 Totvs S.A.
* www.totvs.com.br
*
 

  • get AppServer settings file with problems

Example: appserver.ini
 

If Balance of SmartClient

    • get the SmartClient settings file from the workstation with problem
      Example: smartclient.ini
    • enter description/image of SmartClient execution parameters and the description/image of the error onscreen

If it is WebService Balance or HTTP Balance

When Broker runs as a service:

    • get the operating system logs
      Ex.
      - if in windows:
      "Event Viewer" logs
      - in Linux:
      /var/log/messages
       
  • enter the version of the Broker OS and of Clients OS (when using SmartClient)
     
  • enter whether Broker Server is running in the same computer as the AppServers
     
  • get the network settings of the Broker server workstations and of the clients

Example:
- in windows:
ipconfig /all

- in Linux:
ifconfig -a
 

  • get the server workstation port settings

Example:
- in windows:
netstat -an -p tcp | findstr /i listening
netstat -anb -p tcp

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

Note If the workstation that presented connection problems with Broker is not via SmartClient Desktop, there will be no Broker logs or settings files in these workstations.

 Broker has never connected or no longer connects

If the Broker does not connect, follow these steps and provide the artifacts:

  • Deactivate the Broker Server, make a telnet in your port, and check whether it is not connecting to the port.

Example: telnet 132.7.45.120 8090

If the connection is closing, check which services are improperly active in the computer, replying to Broker Server port (see: get the server workstation port settings)
 

  • Activate the Broker Server, make a telnet in your port, and check whether it is connecting to the port.

Example: telnet 132.7.45.120 8090

If the connection is not closing, check the network infrastructure (cables, firewall, anti-virus, IP and port settings, etc.)
 

  • Test it by deactivating any Firewall and anti-virus that may block the Broker Server port.
     
  • Test to validate the local connection, perform connection tests in the same computer of Broker Server (with SmartClient, telnet, WebService or Browser). If it works, check your network settings, firewall and anti-virus with the administrator.
     

If you cannot identify the problem:

    • provide all artifacts of session "Connection with Broker failed"
 I have problems and use totvs_broker_sg or totvs_broker_sh. What should I do?

This version of Broker has been discontinued and you must update it to the current one.

 

To update the version, follow the instructions in:

http://tdn.totvs.com/pages/viewpage.action?pageId=213979358

 Use of broker for smart client (desktop) with SSL

The broker used with smart client (desktop) is "agnostic" regarding encrypted connections. That is, you can use encrypted connections as usual for as long as appserver and smart client are correctly configured, as specified in the page SSL Configuration in TOTVS Application Server. (Broker operates as a "transparent proxy").
The smartclient.ini file will require section [SSLConfigure], and in the specification of the connection with broker, you will need key SecureConnection.
Example of smartclient.ini for use with broker and secure connection:

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


The configuration of file appserver.ini of broker would be thus:

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


The configuration of file appserver.ini of appserver would be thus:

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

 

 Use of HTTP broker with SSL

You can use the HTTP broker to receive SSL connections from the client, and open non-SSL connections with the server (appserver).

Keep in mind that you cannot ensure that broker will work any and all web applications that use encrypted connections with the browser, due to the enormous variety of techniques employed to write web applications.

In other words, before deploying a web solution in this scenario, you must validate the solution in a lab with the broker set to accept SSL connections.

Another point to consider is that the solution requires validation with specific browsers (example: Chrome and Firefox), due to the fact that distinct browsers behave differently, depending on the resources used when writing the web application.

 

The broker configuration to receive SSL connections requires the following keys in the appserver.ini configuration file:

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

Key SSL_METHOD=SSL/TLS indicates that broker will accept any method chosen by the client.
Key USING_SECURE_COOKIES indicates to broker whether the cookie of broker session will be created as "secure cookie" (with attributes "secure" and "HttpOnly").

 Infrastructure errors

Some operating system errors affect broker operation. When these errors appear in broker logs, they refer to infrastructure problems (hardware, network, operating system bugs, etc.); hence, broker does not cause them.

 

Error 121:

In broker logs it appears as "status 121 (operation timeout expired)".

In the Microsoft website, the error is described thus: "ERROR_SEM_TIMEOUT 121 (0x79) the semaphore timeout period has expired.

 

Error 10050:

In broker logs it appears as "status 10050 (a socket operation encountered a dead network)".

In the Microsoft website, the error is described thus: "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."

 

Error 10051:

In broker logs it may appear as "error 10051" or "network is unreachable".

Windows returns this error when no route exists between an application and the host to which this application is attempting to connect. It can be a configuration error on the list of broker slaves, or it may actually be an infrastructure error.

 

Error 10065: the same as in error 10051, but the corresponding message is "no route to host".

 

As other similar errors are found, they are added to the list.

 Operational or configuration errors

Some errors pertain the configuration or operation of the environment, affecting broker operation. When these errors appear in the broker logs, they indicate that the operation team must take some corrective action. Usually, broker records an event in the Windows log when these errors occur.

 

Error 1225:

In broker logs it may appear as "error 1225" or "connection refused".

It is an error returned by Windows when an application server attempts to connect to a TCP port, though no application is answering in that port. For example, broker attempts to connect to a slave, but no slave is answering in the port to which broker attempted to connect.  The cause could be a configuration error in broker (wrong configuration if slaves), or perhaps the slave was actually offline when broker attempted to connect.

 

Error 10048:

In broker logs it may appear as "error 10048" or "address already in use".

Windows returns this error when a server application attempts to use a TCP port already in use by another server application. In this case, you must find out which other operation is using the port. More rarely, this may occur when the application crashes, or when you force-quit the application in the Windows task manager. This error may appear at broker startup.

 

Error 10051:

In broker logs it may appear as "error 10051" or "network is unreachable".

Windows returns this error when no route exists between an application and the host to which this application is attempting to connect. It can be a configuration error on the list of broker slaves, or it may actually be an infrastructure error.

 

Error 10061: the same as in error 1225.

 

Error 10065: the same as in error 10051, but the corresponding message is "no route to host".

 

As other similar errors are found, they are added to the list.

 Connection log successful (smart client desktop)

In a successful smart client desktop connection with the appserver via broker, we involve 3 log files: broker DLL log, broker log, and appserver log.

Broker DLL log

This log shows several useful data, such as DLL version, the host in which smart client is running, the broker IP and port, the handshake ID and the time of connection opening and closing.

In this example, we must:

   DLL version: 2.0.16

   host in which smart client is running: tec-***** (ip 10.172.78.66)

   broker ip and port: 127.0.0.1:50000

   handshake id: AEF50...52F4F9 (used to trace the connection in broker log)

   time the connection starts: 14:43:34

   time the connection ends: 14:45:26

In this example, notice that as the connection took place without errors, the line with the message "creation of new connection successful" appears; then, after some time (taken by the user to operate the smart client), the line with the message "client connection closed remotely" appears, after the user closed the smart client as usual.

Broker log

In the corresponding broker log, we also have several useful data, but the interesting thing in this example are the smart client connection opening and closing sequences.

We can se in the line with the message "received initial handshake from client" the same id AEF50...52F4F9 found in the DLL log. This line shows another important piece of information: the "context" associated to this connection: ctx:008. All log messages related to this connections will be associated to this context "ctx:008". Thus, we can isolate the messages related to specific connections, even if many smart clients use the same broker.

The opening sequence of a successful connection starts with the message "initial handshake received" and proceeds to the line "creation of new connection successful". From this point onward, smart client converses normally with appserver (it will appear in the server monitor).

The regular closing sequence starts with the line "client connection closed remotely" (that is, smart client has closed the connection) and continues to the line "error, connection closed by server in standby mode". The reason for this "error" line is that broker does not know the connection is being normally closed. Thus, when smart client closes the connection, broker leaves the connection on standby, but soon thereafter the appserver closes the connection (which is normal), causing this "error" message in the broker log.

Notice that in this test example only one smart client is in use, so all lines related to this smart client appear on a sequence in the broker log. In a normal scenario with multiple smart clients, messages pertaining several smart clients are scrambled.

Appserver log

The appserver log related to this connection shows the start and the end, without any further information, because the test only comprised a few screen exchanges. Notice again that, as only a single smart client was connected, the messages of connection start and end appear on a sequence, one right after the other.

Pay attention to the timekeeping records in the 3 logs. In the DLL log, the actual start of connection was at 2:43:34 PM, in the broker log also at 2:43:34 PM, and in the appserver log at 2:43:37 PM. The closing appears in the appserver log at 2:45:26 PM, in the broker log at 2:45:26 PM and in the DLL log also at 2:45:26 PM.

 Connection log: configuration error of broker ip in smartclient.ini (smart client desktop)

In this example, broker is configured in smartclient.ini with IP 123,123,123,123. DLL attempts to connect to this IP but receives no answer, so after approximately 23 seconds Windows returns error 121. DLL closes the connection with smart client, which then closes the connection error screen. (What probably happened is the connection request left the corporate network to the Internet, where some router or server dismissed it. PS: this IP is from Beijing, China). 

 Connection log: configuration error of broker port in smartclient.ini (smart client desktop)

In this example, the broker is configured in smartclient.ini with port on 8002 at the local computer (127.0.0.1), but no broker is responding in this port. DLL attempts to connect to the broker in 127.0.0.1:8002, but Windows responds immediately with error 1225. DLL closes the connection with smart client, which then displays the connection error screen. 

 Use of more than 99 balanced servers

For more then 99 servers, use letters (A to Z) to compose key REMOTE_SERVER_xx, because this key must only contain 2 identification characters.

For example:

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


Any combination of letters and numbers (2 characters) is acceptable.



  • No labels