WebLogic Server - Apparent Memory Leak in Java Heap due to Weblogic JMS 'C' Api
Last updated on DECEMBER 11, 2017
Applies to:Oracle Weblogic Server - Version: 10.3.3
Information in this document applies to any platform.
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
running on top of Microsoft Windows 2008 on x64.
You might be facing an issue with memory leak in the Java Heap when using the WebLogic JMS "C" API.
You might then suspect a memory leak in the Weblogic JMS calls while using a QueueBrowser. It was observed that the java client which directly calls the wljmsclient.jar/wlclient.jar does not exhibit this memory leak. However the C++ version which calls the Weblogic JMS "C" API displays this memory leak.
You might think that the C++ version of the code which was invoking WLS JMS C code in turn was giving instances of a memory leak on java heap.. Further review of the WLS code base revealed that the JNI function is being called inside the JMS "C" code provided with WLS.
Studying the heap histograms produced using jhat. These are the numbers that jhat produced, for the top 6 classes, after 200000 iterations of a reproducer.
|Class||Iteration 16900||Iteration 110000||Iteration 152200||Iteration 200000|
|class [B ||0.7MB||0.4MB||0.8MB||2.3MB|
|class [I ||1.6MB||1.0MB||2.2MB||0.8MB|
This clearly shows that the JMSEnumeration and JMSQueueBrowser classes are not being removed at all. Each iteration allocates one each of these classes, and then destroys or closes the connection object. The above shows evidence that the allocated objects from classes JMSEnumeration and JMSQueueBrowser are never removed.
The JMSEnumeration and JMSQueueBrowser classes show growth that is exactly linear with the number of iterations. So while [C, [B, [I, and "[Ljava.lang.Object" all show evidence of having been garbage-collected, the other two classes have not been.
That's good evidence that the references to JMSEnumeration and JMSQueueBrowser objects in the Java heap are not being deleted at the appropriate time, while references for all the other Java objects apparently *are* being deleted, and later garbage-collected.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms