Topics

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.

Ryan Lubke <ryan.lubke@...>
 

At first blush it would appear that the listeners that are invoked when the server-side connection is closed aren't being invoked to cleanup the state being maintained to support HTTP/2.

I'll find some time this week to see if I can replicate.

Another possible workaround if you're mostly concerned with supporting WebSocket+TLS is to disable HTTP/2 on the listener in question (http2-enabled=false).

info4andrey@...
 

Hi there!

I do confirm the issue mentioned by "zakimak9@...". Got the same results after checking the heapdump from pre-prod server.

Thanks!