Tracing the wsconfig utility's TCP communications to a JRun server reveals communication over ports other than the JNDI port. In fact, after wsconfig establishes a connection over the JNDI port, the JRun server instructs wsconfig that JRun will now listen on a random port and that wsconfig is to complete the communications over that new port through a new TCP connection.
The wsconfig utility is used by ColdFusion and JRun servers to configure external webservers to the appropriate application server. One type of configuration is referred to as Distributed Mode where the webserver is on one machine and it will use the JRun connector to communicate with the ColdFusion or JRun server on another machine. In this situation there may be a firewall between the two machines, for example, which could potentially block the required TCP communication between wsconfig and JRun when initially installing the connector for the webserver.
Knowing that wsconfig will perform a port scan on the JRun server machine starting at port 2900 until port 2999 enables the user to prepare the firewall to permit a connection from the webserver to the JRun server over the JNDI port by TCP.
Identifying the JNDI port
The JNDI port for a JRun or ColdFusion server can be determined in a number of ways.
- The JNDI port number can be found by reading $CFHOME/runtime/servers/default/SERVER-INF/jndi.properties, looking for the port number at the end of java.naming.provider.url
- The same port is shown in the start up sequence in the $CFHOME/runtime/logs/default-out.log such as
"info JRun Naming Service listening on *:2901". - netstat -an can be used to confirm the port is actively being listened to on
TCP 0.0.0.0:2901 0.0.0.0:0 LISTENING
However, an undocumented and little known aspect of wsconfig is that once communications are established over the JNDI port by RMI, the remainder of the configuration occurs by communication over a random port, making it difficult to know how to adjust any firewall rules to permit the TCP connection over the new random port.
Could not connect to any Jrun/ColdFusion servers
If either the JNDI port or the secondary random port are blocked between the webserver and the CF/JRun server, then you may enounter the error:
Could not connect to any Jrun/ColdFusion servers on host localhost.
Possible causes:
Server not running
-Start Macromedia JRun4 or ColdFusion MX server
Server running
-JNDI listen port in jndi.properties blocked by TCP/IP filtering or firewall on server
-host restriction in security.properties blocking communications with server
Its even possible to use netstat to see that the JNDI port has an ESTABLISHED connection or maybe a TIME_WAIT connection lingering, which is good evidence to confirm that TCP connections to the JNDI port are not bocked. If you can see the JNDI port active in one of these states but still get the error above, then very likely it is the other, random port being blocked.
You may want to check this blog posting for the other, more typical reasons for why this error might occur.
Tracing wsconfig TCP communication
Below are highlighted traces taken while using the Ethereal Network Analyzer (a packet sniffer) to watch the wsconfig TCP communications in a distributed configuration. The trace shows the normal events during wsconfig communication with the JRun/CF server where a firewall is not in operation between the two hosts.
- 1a) Here the port scan begins, starting at port 2900. A synchronize (SYN) flag is sent to the JRun host on each port in the port range. If the remote host does not respond to that port then reset flag is returned (RST, ACK).
- 2a) A SYN flag to port 2909 was responded to with a synchronize/acknowledge flag (SYN, ACK) indicating that something is active on that port on the remote host.
- 1b) The port scan continues until port 2999.
- 2b) Any established connections made during the port scan are finished (FIN, ACK) and closed. The wsconfig util assumes that active ports during the scan might be active JRun servers.
- 3) A new TCP connection is established to those ports that were active during the port scan. Here some initial data is transmitted via RMI. During this communication, JRun instructs wsconfig that JRun will be listening on a new randomly chosen port number, and wsconfig should contact JRun over that port.
- 4) wsconfig establishes a new TCP connection to JRun over the new port using RMI. Much communication occurs with the JRun server over this new port using RMI. In this example, the new port is 1523. Predicting this port may be difficult, and a firewall blocking that port will cause the error above.
|
