The scope of this article is to troubleshoot GPText startup/segment recovery issues related to ports being already in use.
GPText-start or GPText-recover will fail and in the solr startup.log shows an error similar to the following:
java bind exception - address already in use
FAILED email@example.com:1254: java.net.bindexception
- Check which process is currently using the same specific port
- Check if solr.xml and jetty.conf files are correct in the segments
- Check the local port range in the Linux system: sysctl -a | grep net.ipv4.ip_local_port_range
As the error message suggests, the cause for this is that a GPText Solr instance cannot bind to its specified port because some other process is already using it.
Checking the local port range in the system might give an output similar to:
net.ipv4.ip_local_port_range = 1025 65535
This would mean that ports can be allocated by the OS for TCP and UDP traffic in a range from 1025 to 65535.
By default, GPText normally uses ports 11xx and 12xx and it can happen that another process is bind to one of those, as these port numbers fall inside the system port range 1025 < 11xx < 12xx < 65535.
GPText ports should be out of the range set by "net.ipv4.ip_local_port_range". Otherwise, there is a risk to encounter port conflict issues.
In order to do so we can reconfigure "net.ipv4.ip_local_port_range" parameter.
- Stop GPText: gptext-stop
- Stop GPDB: gpstop -af
- As root, apply the following changes to all segment servers:
- Change /etc/sysctl.conf parameter "net.ipv4.ip_local_port_range" to a range not overlapping with GPText ports (for instance, "net.ipv4.ip_local_port_range = 1300 65535")
- Reload sysctl.conf: sysctl -p
- Restart network service: /etc/rc.d/init.d/network restart
- Start GPDB: gpstart -a
- Start GPText: gptext-start
Note: To get current GPText configured ports, run gptext-state when GPText is up, or get the information from the jetty.conf files in the segments. GPText ports are specified during the GPText installation.