java.net.BindException: Address already in use: JVM_Bind <null>:8080

This can be caused if you already have Tomcat running as it will hold onto a network port for handling HTTP requests. In the above example the port shown is 8080.

However, this error is sometimes apparent even when Tomcat has already been shut down, expecially if you’ve shut it down abruptly. The problem here is that the Tomcat process may not have completely ended and that Windows is holding onto the network port for it.

To resolve this do the following:

1. find the process ID that has the port reserved,
2. kill the process, releasing the port.

Step 1 – Find the process thats holding onto the port

Start a command prompt and enter the command:

netstat -ano

The flags for this cause (a)  all connections and ports to be listed, (n) port numbers to be shown numerically, and importantly (o) which causes the process ID to be included in the output. The results of running this should look something like this:

Active Connections

Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       496
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:1776           0.0.0.0:0              LISTENING       1128
TCP    0.0.0.0:2864           0.0.0.0:0              LISTENING       2524
TCP    0.0.0.0:3306           0.0.0.0:0              LISTENING       1708
TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       424
TCP    0.0.0.0:6942           0.0.0.0:0              LISTENING       2524
TCP    0.0.0.0:8008           0.0.0.0:0              LISTENING       1292
TCP    0.0.0.0:8009           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:8012           0.0.0.0:0              LISTENING       1456
TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:8443           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:15000          0.0.0.0:0              LISTENING       1864
TCP    0.0.0.0:33115          0.0.0.0:0              LISTENING       704
TCP    0.0.0.0:63342          0.0.0.0:0              LISTENING       2524
TCP    10.136.38.94:139       0.0.0.0:0              LISTENING       4

In the output, port 8080 (under Local Address, on line 14) can be seen to belong to process ID (PID) 2904.

Step 2 – Kill the process

Press <CTRL><ALT><DEL> and then select Task Manager, then from the Task Manager choose the menus: View | Select Columns. In the dialog that appears check the PID checkbox to display the process ID and then dismiss it by pressing OK.

With the Processes tab selected you should be able to idenify the process with the PID that we found in step 1. In this example the value would be 2904.

Select this process and click End Process. Confirm that you want to kill the process and you should find that once it has been killed off, the network port it was holding has been released.

This technique has the following advantages:

• Your Java bean’s methods can be triggered manually and interactively (great for application development and management)
• Has minimal impact on the code you write (only annotations are used)
• Simple to configure using Spring
• Works for stand-alone applications and server based ones too (the following discussion demonstrates this using Tomcat)

What are JMX and Spring?

JMX provides a standard means of accessing, and interacting with, objects within a running process. An object that exposes itself via JMX is known as an MBean, if you’re looking for a more detailed overview of JMX, try this excellent introductory article on JMX by Brian Goetz.

Spring is a comprehensive open-source framework which can greatly simplify the development of all types of Java applications

In this article, a basic understanding of both JMX and Spring is assumed.

Configuring Spring

There are a few ways of doing this. This is my favourite approach though as it is the least invasive to your Java code (as you’ll see later on) :

<!-- Expose all annotated beans as JMX MBeans -->

<bean id="exporter"

      lazy-init="false"
      p:autodetectModeName="AUTODETECT_ASSEMBLER"
      p:assembler-ref="assembler"
      p:namingStrategy-ref="namingStrategy"/>

<bean id="assembler"

      p:attributeSource-ref="annotationAttributeSource"/>

<bean id="namingStrategy"

      p:attributeSource-ref="annotationAttributeSource"/>

<bean id="annotationAttributeSource"
     />

The exporter will identify which of your application classes should be exported as JMX beans. If your application classes support the JMX management interfaces then this class can be used to detect and export your beans automatically for you (just set the autoDetectModeName property to AUTODETECT_MBEAN).

A simpler approach, which relies on you simply annotating your POJO classes, is to configure the exporter to use an assembler (to identify which beans should be exported) and a naming strategy (to decide what names will be used for your beans when they are exported to the JMX server). Note in the above example how the assembler and namingStrategy properties have been set to use this approach.

Both the assembler and the namingStrategy delegate their method calls to the annotationAttributeSource bean (c.f. the Strategy design pattern) which examines the beans in the Spring context for annotations to determine whether the beans are to be exported and what their names should be respectively.

Annotating Your Java Code

So now that Spring is configured to look for annotated classes, all you need to do is annotate your classes to indicate whether they should be exported as JMX services:

@ManagedResource(objectName="bean:name=BatchProcessor")
public class BatchProcessor {

    @ManagedOperation
    public void startBatch() {

    }
}

The ManagedResource annotation indicates that this class should be exported, and the objectName attribute specifies the JMX bean name.

The ManagedOperation annotation should be used to indicate which methods on this class should be accessible via JMX; by default methods are not made available. Both of the above annotations allow for general information to be set too, for example a description of the bean or the method.

Configuring the Java Runtime

Any J2SE 5 (or later) runtime provides support for JMX. In order to use it, certain system properties must first be set.

For example, if you wanted to activate JMX in Tomcat, then you’d need to add these system properties to the start-up script:

set CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

In this example, no security has been set for the Tomcat process. You should ensure that you configure JMX appropriately for your environment.

Using JConsole to Access Your MBeans

JConsole is an application that ships with the current JDK from Sun. It provides a graphical user interface for accessing JMX beans running in remote processes.

You can launch JConsole from the command line:

$ jconsole

When it starts, you’ll be asked to enter a URL for the JMX server you want to attach to. The above configuration specified that the JMX port should be 8086. If you’ve used the same configuration, then, once Tomcat has started, enter localhost:8086 and click on the Connect button.

Once connected, you can examine the JMX beans. Different versions on JConsole present these differently, the current version lists them under the MBeans tab, and under the beans node in the tree shown on the left. From here you can interactively invoke the methods on your beans and set or get their properties.

Conclusion

Exposing your application services in JMX provides a simple and effective means of accessing functionality that would only otherwise be available to the running application. This is particularly useful when manual intervention is sometimes required; for example, to manually launch a batch processor that’s embedded in the application.