Kbase P143883: The AppServer broker is using a port already defined in the /etc/services file for a database broker
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
08/07/2009 |
|
Status: Verified
SYMPTOM(s):
Occasionally, trying to manually or automatically start a database server results in a port already in use error.
The port <n> is already in use. (12036)
** This process terminated with exit code <number>. (8619)
The additional port listed in the lsof output after starting the AppServer is also one of the ports defined in the /etc/services file for the database servers.
FACT(s) (Environment):
IBM AIX
OpenEdge 10.1B
Each time the AppServer broker is started, it seems to listen on an additional port to the one defined in the ubroker.properties file.
This additional port number changes each time the AppServer broker is stopped and started.
The ports used in the commands to start the database brokers and servers are defined in the /etc/services file.
After starting an AppServer, the output from running an lsof command shows that an additional port is used by the AppServer broker.
The command: lsof | grep TCP | grep LISTENING | grep <userid of the process that started the AppServer broke>
shows that there is an additional port that the AppServer broker process is listening on.
The port numbers defined in the /etc/services file for the database servers are above 32768 (32K).
The additional port is used by the AppServer broker to communicate with the AdminServer.
The AppServer broker is a java process and it calls a java RMI method to get a free port to use to communicate with the AdminServer.
CAUSE:
Since a specific port number is not used in the java RMI method call, an ephemeral port is taken off the IP stack. That java method does not check the /etc/services file to see if the port is already defined there, so by chance, a port number was returned for a service already defined in the /etc/services file. The database broker's request to bind to that port was refused since the AppServer broker was already bound to it.
FIX:
There are three options that can be tried to avoid this port conflict:
1. If your configuration allows, start the database(s) before starting the AdminServer and AppServer(s) so that the database servers can bind to the ports defined in the /etc/services file first.
2. Change the port(s) that the database(s) use to be outside the ephemeral port range.
3. Change the ephemeral port range if your operating system allows.
This option should be chosen with caution since any changes that decrease the port range could result in running out of available ports. Ephemeral ports are made available for reuse once the connection ends. However, most IP stacks will not reuse that port number until the entire pool of ephemeral ports has been used. Once a port has been released, it cannot be reused until the TIME_WAIT state has expired. For example, even if both sides of a TCP connection close properly TCP's error control mechanism requires that each side must wait for the TIME_WAIT state to expire before that connections resources can finally be terminated. The TIME_WAIT state is twice the value of MSL, the Maximum Segment Lifetime, which depending on the IP stack is typically set at 240 seconds. If the ephemeral port range is too small, and there are enough connects and disconnects in a relatively short period of time, it is possible to exhaust all of the ports.