Network Ports

Determining currently used network ports

A default installation of Weave uses up to three different network ports, one for the client to connect to, one for the shutdown process to connect to to tell the Weave instance to stop when Weave is started from the startup script, and one to provide telnet access to the running instance so that you can issue OSGi commands directly to the running Weave instance.

These ports must be different for each instance of Weave that is running on the same server at the same time or the server may not start. Depending upon if the instance is being started as a service/daemon or from the startup script the current values for these port numbers can be found in different locations.

Network ports for Weave 2.4 and 2.5

HTTP Port

The HTTP port that the client connects to is generally set in the jetty.xml file. One of the things that file configures is the connector for HTTP requests that will have a line like:

            <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

Where it's setting the port for the connector based in the system property names jetty.port, and if that value is not set then it will use 8080. 99% of the time there will not be a system property named jetty.port set, so 8080 (or whatever value you have) will be used. I'm going to assume for the moment that if you do have jetty.port set then you have enough knowledge to figure out what port numbers are being used and don't need my help in this section.

Shutdown Port

If Weave is started from the startup script, as opposed to being started as a service, then there is a setting in the startup.sh/startup.cmd and shutdown.sh/shutdown.cmd files which tells Weave the network port it should listen on when starting, and talk to when being ask to shut down. This is the stop port and will be specified as a system property in both the startup and shutdown files like this:

-DSTOP.PORT=8070

and should be kept as the same value in both the startup and shutdown scripts.

If Weave is running a as service on Windows then the service wrapper will take care of starting/stopping the the instance so you do not need to worry about the stop port. If Weave is running as a daemon on Linux then this will generally also be the case.

Telnet Port

If it is enabled then Weave will also listen on a network port using the Telnet protocol which allows you to communicate with a running Weave instance, which is particularly useful if Weave is running as a service/daemon.

If the Telnet port is not set the Telnet service will not be enabled, and you would not have to worry about the port conflicting with other Weave instances running on the same server.

Telnet port when running as a service

To find the current Telnet port number when running as a service/daemon you should look at the weave-service.conf file. If the port is enabled then there will be a wrapper.java.additional property set like:

wrapper.java.additional.12=-Dosgi.console=9001

The number 12 in this example may be different in your file, but if it is set then it indicates that the Telnet port is available and what port number it's listening on.

That the line may exist in that file but be commented out, if it's preceded by a # character, in which case the Telnet service is not enabled.

Telnet port when running from the startup script

The Telnet port can also be enabled in the startup scripts, but is less common. In this case the startup script will also set the osgi.console system property to the Telnet port number that it wants to listen on.

SET JAVA_OPTS=%JAVA_OPTS% -Dosgi.clean=false -Dosgi.console=9001

JAVA_OPTS="$JAVA_OPTS -Dosgi.clean=false -Dosgi.console=9001"

The startup script may have the osgi.console system property set, but not have it set to a port number, in this case it's enabling the OSGi console, but not starting the Telnet service to be listening on that port.

It may also not have the osgi.console value set at all, which also disables the Telnet service.