Troubleshooting file leaks in java applications

Recently I was diagnosing a production issue related file handle leaks. The setup was as follows – There were two applications. Application A was an ETL process that loaded the input file into the system and Application B that deleted these input files after A completes. Application B randomly failed with an error that stated that the file was still being used by another process.

Advertisement

Identifying jar dependencies

Recently I had to find dependencies between the jar files included in my web application and I came across JBoss Tattletale! Its a tool that does many things including finding jar dependencies

It generates reports as HTML files. The main HTML file is index.html. The reports include following details.

Jstack Error – Not enough storage available

JStack is nice tool to print thread stack traces for a given java process. It comes to be very handy when analyzing high cpu usage problems. At times when executing this command you may encounter an error like I did 🙂

“Not enough storage is available to process this command”

It appears that on Windows Vista and later jstack doesn’t work because the command might be executed from a different user account then the one under which the jvm is running. The error doesn’t have anything to do with memory. So possible solutions to this are

1. Run jstack under the same account as the jvm
2. Use psexec to execute the jstack command like

psexec -s "%JAVA_HOME%\bin\jstack.exe" PID >stack.txt

Hope that helps !

Java Decompiler – JD-GUI Features

Recently I came across some really nice features of the jd-gui java decompiler. This decompiler seems to behave as an IDE for reading class files. I am using the 0.3.3 version of the library.

Unloading of static fields in java

I came across this interesting article about loading and unloading of static fields which details a couple of facts I was not aware of
1. Loading – You can get a reference to a class, before it has been initialized (i.e its static fields being initialized or its static initializers being called), only when it is used does it get initialized. The link contains an example code which illustrates this fact.
2. Unloading – Static fields are unloaded when the Class’ classloader is unloaded. This is unloaded when a GC is performed and there are no strong references from the threads’ stacks.

This post adds more detail to the second point. Below are few reasons why classes are unloaded only when the classloader unloads.

Java 7 Feature Guide

A good concise guide to all the jdk7 enhancements can be found here. Some interesting ones are –

Scalable file I/O support
Many of the java.io.file methods did not scale. Requesting a large directory listing over a server could result in a hang. Large directories could also cause memory resource problems, resulting in a denial of service. The new file I/O package is implemented so that it works regardless of the file system’s size.

Watching a directory for changes
The Watch Service api allows you to register a directory for file change notifications. An application can register for creation, deletion, or modification events. This feature can be implemented using the FileVisitor API to recursively watch an entire file tree for changes. For more information, see Watching a Directory for Changes (Java Tutorial).

Uncaught Exception Handling and ThreadDeath

Java uses (or in more specific terms, throws) exceptions to notify exceptional situations in programs. Developers write try-catch blocks to handle these exceptions, or simply propagate the exceptions upwards in the call stack.

An uncaught exception is a Throwable, which is not caught by any part of the application in the call stack where the exception occurred. It has propagated through the call stack, and has arrived at the underlying thread (could be the main thread or a defined thread), without being caught. Java actually handles uncaught exceptions according to the thread in which they occur. When an uncaught exception occurs in a particular thread, Java looks for what is called an uncaught exception handler, actually an implementaiton of the interface UnCaughtExceptionHandler.

The specific procedure is as follows. When an uncaught exception occurs, the JVM does the following:

• it calls a special private method, dispatchUncaughtException(), on the Thread class in which the exception occurs;
• it then terminates the thread in which the exception occurred

The dispatchUncaughtException() method, in turn, calls the thread’s getUncaughtExceptionHandler() method to find out the appropriate uncaught exception handler to use. Normally, this will actually be the thread’s parent ThreadGroup, whose handleException() method by default will print the stack trace.

Java Proxies and UndeclaredThrowableException

A common approach in Java is to use dynamic proxies to provide decorator-style behavior. Doing this allows you to add additional behavior “around” an object without the object itself or it’s callers being aware of the decorating.

Let’s take an common implementation of java proxy.

public interface InterfaceA {
    void display() throws SQLException;
}

public class ClassA implements InterfaceA {

    @Override
    public void display() throws SQLException {
        throw new SQLException();
    }
}

public class ProxyHandler implements InvocationHandler {

    private InterfaceA delegate;

    public ProxyHandler(InterfaceA delegate) {
        this.delegate = delegate;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("Inside the invocation handler");
        return method.invoke(delegate, args);
    }
}

public class ProxyApp {
    public static void main(String[] args) {
        createAndTestProxy();
    }

    private static void createAndTestProxy() {
        InterfaceA interfaceA = (InterfaceA) Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
                                                    new Class[]{InterfaceA.class}, new ProxyHandler(new ClassA()));
        try {
            interfaceA.display();
        } catch (java.sql.SQLException e) {
            throw new RuntimeException("Something bad happened", e);
        }
    }
}

If you run the ProxyApp class to test the proxy implementation, you would get the below exception trace

Inside the invocation handler
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
	at $Proxy0.display(Unknown Source)
	at proxy.ProxyApp.createAndTestProxy(ProxyApp.java:23)
	at proxy.ProxyApp.main(ProxyApp.java:16)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:110)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at proxy.ProxyHandler.invoke(ProxyHandler.java:26)
	... 8 more
Caused by: java.sql.SQLException
	at proxy.ClassA.display(ClassA.java:18)
	... 13 more

The expected stacktrace should have been

Inside the invocation handler
Exception in thread "main" java.lang.RuntimeException: Something bad happened
	at proxy.ProxyApp.createAndTestProxy(ProxyApp.java:25)
	at proxy.ProxyApp.main(ProxyApp.java:16)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:110)
Caused by: java.sql.SQLException
	at proxy.ClassA.display(ClassA.java:18)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at proxy.ProxyHandler.invoke(ProxyHandler.java:28)
	at $Proxy0.display(Unknown Source)
	at proxy.ProxyApp.createAndTestProxy(ProxyApp.java:23)
	... 6 more

Text Search In Jar Files

I found this  tool which can be help you to do a text search in jar files. Just execute the below command to start the application

java -jar Javinder.jar

Here is a sample snapshot

Guava Immutable Collections vs Collections.unmodifiable

Java Collections

Collections.unmodifiableList or Collections.unmodifiableSet methods create a wrapper around the original list or set. Hence any changes to the original list would affect the unmodifiable list too.

Set<String> x = new HashSet<String>();
x.add("foo");
Set<String> builtIn = Collections.unmodifiableSet(x);
x.add("bar");
System.out.println(builtIn.size()); // Prints 2

It would be more clear if you have a look at the implementation of Collections.unmodifiableList() method