Port numbers in the
etc/services file cannot be reserved so that they aren’t used other processes. Remote ABL servers (_mprosrv) have an internal code check since OpenEdge 10.2B08, 11.2, or later that prevents a remote server starting on a port already associated with a Service name.
It is important to understand the following:
- Entries in /etc/services are only about associating a Service name to a port number, not about reserving port numbers on a Server.
- A remote server is not a Service. The Database Server is a Service that spawns remote servers.
- For U Brokers, the -port configured in the ubroker.properties will be used if the port is in the etc/services as long as it is not currently being used by something else.
- For Agents, the -srvminport -srvmaxport range will be used if the ports are in the etc/services and are not currently used by something else.
- For the Database Server, the -S portnumber will be used if the port is in the etc/services and are not currently used by something else.
- For the Database Remote ABL Server (_mprosrv), the next port found in the -minport -maxport range will not be used if these ports are in the etc/services even if they are not currently used by something else. We assume that since the port is associated with a Service name, they must be defined for a good reason to another program, therefore we will skip this port and move on to the next available port in the -minport -maxport range when starting a remote ABL Server. This issue does not affect the Database Remote SQL Server (_sqlsrv2) process because it uses a different code set and does not block on ports defined in the services file.
Why are remote ABL Server handled differently Improvements to OpenEdge10.2B08, 11.2, or later introduced a check for the port being reserved in the /etc/services file, before spawning a remote ABL server on that port.
Previously, if a port in the -minport -maxport range was reserved in /etc/services
- A remote ABL server would be spawned on that port (there was no check)
- Clients would not be able to complete their 3-way-handshake connect (Pending Connections would result)
- Eventually -Mn would exhaust (remote servers would be spawned, with no clients connected)
Which is why a specific check to not spawn a remote server on a port in the etc/services was implemented, in order to prevent the situation from occurring.
For example:If I start a database server on port -S 25000, with -minport 25001 -maxport 25009 and all these ports are associated to a Service name etc/services:
- I can start the Database Broker (if port 25000 is not taken by another process),
- I'll never be able to spawn an ABL server on port 25001 to 25009 (as they are present in /etc/services even if not used)
- However I will be able to spawn a SQLSRV2 on port 25001 to 25009 (if they are not currently in use)
For Database Remote ABL Server (_mprosrv), ensure that Remote Servers are spawned in a port range that are not included on ports already listed for Services in the /etc/services file, by configuring the -minport and -maxport database startup parameter range for remote servers on the login broker.
