Monday, February 25, 2013

Glassfish 3.1.2.2 Web Service Memory Leak

I recently installed Netbeans 7.3 with the Glassfish 3.1.2.2 combo, and decided to play with it. So i deployed a simple application that exposes an "echo" web service.
@WebService(serviceName = "EchoWebService")
public class EchoWebService {

    @WebMethod
    public String echo(@WebParam(name="text") String text) {
        return text;
    }
}
Then using JMeter, i stressed the service to see how the server performs: a simple test plan that consists of a group of 5 threads, each thread sending continuously a HTTP request to the web service. The request contains a SOAP envelope holding the parameter that must be echoed by the web service.

JMeter Sampler - HTTP Request with SOAP Envelope

This chart illustrates the performance monitored within JMeter (in request per second):
Echo Web Service - Requests per second
As you can see, after 2:24 mn the server starts performing very badly .. and after almost 5 minutes i stopped the load test.

During the test, i monitored the server's memory with JConsole:

JConsole - Heap Usage
The graph shows that objects created during the test are not freed by the garbage collector and at the end the JVM is spending most of the time in trying to free some memory.

At this point, i ran the test another time and forced a heap dump to got some clue about the memory leak.

The analysis reveals that the leak comes from the com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl component that holds an instance of a java.util.HashMap$Entry[] where 91% of the memory is accumulated:
Memory Analyzer Tool - Report
This array is full of org.glassfish.weld.services.JCDIServiceImpl$JCDIInjectionContextImpl instances (524 488 instances).

I do not know if it is a known issue, or if there is something wrong with my modus operandi.


3 comments:

  1. I thihnk that you should report a bug.

    ReplyDelete
  2. Actually, someone has already report the bug for the v3.1.2: http://java.net/jira/browse/GLASSFISH-18768. The fix is planned for the v4 release.

    ReplyDelete
  3. This is completely typical and the reason why Java server side is non-existent. They fail so hard.

    Another bug that I just discovered is the use of FOP and performing a transform where the xml document in stream source is given as a StringReader and the style sheet is gotten by getClass().getResource(). When calling the javax.xml.transform.Transformer transform method the transform on Glassfish 3.1.2.2 takes over a minute - if it returns at all.

    On Glassfish 3.1.1 the transform takes about a second.

    The Java EE platform is always 1 step forward, 2 steps back. I am currently phasing out all Java EE work on the server side with PHP. Not necessarily because I have any sort of love for PHP. But because I can't spend time attempting to track down amateur-hour updates done by the Oracle monkeys.

    ReplyDelete