GlassFish 5 Build 25 : Websocket and possible memory leak suspects - org.glassfish.grizzly.http2.AlpnSupport, sun.security.ssl.SSLEngineImpl

zakimak9@...
 
Edited

Hi,

We have been carrying out load tests using JMeter. The server is hosting a WebSocket solution and the test tries to create about 2000 WebScoket connections. It tries to simulate frequent network disconnections. So for every 2000 user/connection we are doing a forced disconnection and then connect again after about 30s. The disconnection is made after about 5 mins of establishing connection. The test was run for 6 hours without any issue. We have allocated 6GB as Min and Max heap. Once test completed we left the server running idle and after several hours we checked back the heap memory consumption and it seemed to occupy about 3.5 GB of heap memory. A heap dump was taken and analyzed via Eclipse MAT. We see the following suspects in the report:

Problem Suspect 1
 
The class "org.glassfish.grizzly.http2.AlpnSupport", loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x640b97728", occupies 2,243,734,264 (67.17%) bytes. The memory is accumulated in one instance of "java.util.WeakHashMap$Entry[]" loaded by "<system class loader>".
 
Keywords
java.util.WeakHashMap$Entry[]
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x640b97728
org.glassfish.grizzly.http2.AlpnSupport
 
Problem Suspect 2
 
37,243 instances of "sun.security.ssl.SSLEngineImpl", loaded by "<system class loader>" occupy 851,020,064 (25.48%) bytes. These instances are referenced from one instance of "java.util.concurrent.ConcurrentHashMap$Node[]", loaded by "<system class loader>"
 
Keywords
java.util.concurrent.ConcurrentHashMap$Node[]
sun.security.ssl.SSLEngineImpl

It would be great if you could shed some light on this.

Update

To overcome this issue I have stopped using SSL and the leak subsided.

Join glassfish@javaee.groups.io to automatically receive all group messages.