by Fabian Lange

In Act 5 of our OutOfMemoryError series, I talked about the lack of tool support for finding memory leaks at runtime. I got some negative feedback on dzone, because the tool I discussed was commercial 🙁

Shortly after I published that post, I got notified of a product called “plumbr“. Plumbr is in beta phase, which means it is free at the moment, and they even have a public pricing discussion. But still we need to accept, that there is no free solution. Its not my fault, so don’t be angry 🙂

In this short update, I will show you how plumber will find the very same memory leak, which AppDynamics found in my last article.



Installation

Plumbr is as easy to install as AppDynamics. Your downloaded package contains files for various platforms, so this is an indication, that plumbr is using a JVMTI native agent in addition to the javaagent. After unzipping, I needed to add this to my Tomcat 7, which will be running the memory leak app:

SET PATH =C:\Tools\plumbr\plumbr\win\ 64 ; % PATH % set CATALINA_OPTS =-agentlib:plumbr -javaagent:C:\Tools\plumbr\plumbr\plumbr.jar SET PATH=C:\Tools\plumbr\plumbr\win\64;%PATH% set CATALINA_OPTS=-agentlib:plumbr -javaagent:C:\Tools\plumbr\plumbr\plumbr.jar

Finding Memory Leaks Fast

Plumbr is working very fast. I deployed my leaking application and started the load script. After only a few minutes this messaged appeared:

So the only thing I needed to do was to open the generated report:

Tadaa! The leak was correctly identified. And it also lists where the leak comes from, which is very important:

The objects are created at de.codecentric.memleak.leak.StringQueueLeak.leak(de.codecentric.memleak.domain.Bookmark):58

When compared to AppDynamics, this is slightly less information, because the call stack is shorter. And it also does not give invocation counts. However this is still great information, which helps us to identify and fix the leak. And it is presented in a dead simple way.

Further improvements

You might wonder why there are 3 leaks identified, while AppDynamics did show only one of them. The second and third are classes used by the Derby database:

So plumbr currently assumes that a reference from java.lang.ref.Finalizer is a memory leak. There is some controversy (for example on stackoverflow) about this being possible leaks. So I mailed this observation to the plumber developers and got a quick answer: While they think Finalizers are problematic, they want to change the handling, so there will be less likely false positive reportings.

I think plumbr is a really interesting solution. It solves the very specific problem of finding memory leaks in an elegant way. It reports fast and did not add significant overhead to my application, but I still have to trial it in a real application server environment to make an educated statement.