WebLogic Server - Apparent Memory Leak in Java Heap due to Weblogic JMS 'C' Api (Doc ID 1310342.1)

Last updated on NOVEMBER 05, 2016

Applies to:

Oracle Weblogic Server - Version: 10.3.3 and later   [Release: and later ]
Information in this document applies to any platform.

Symptoms

In the context of WebLogic Server 10.3.3.0.0, running on top of the JVM:
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
weblogic.jms.client.JMSEnumeration
0.7MB
4.4MB
6.1MB
8.0MB
weblogic.jms.client.JMSQueueBrowser
0.7MB
4.4MB
6.1MB
8.0MB
class [C
0.6MB
0.5MB
0.7MB
1.3MB
class [B
0.7MB
0.4MB
0.8MB
2.3MB
class [I
1.6MB
1.0MB
2.2MB
0.8MB
class [Ljava.lang.Object
0.1MB
0.1MB
0.1MB
0.4MB

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.

Changes

Customer suspected 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.

Cause

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