[jira] [Commented] (WICKET-6965) Memory leak in WicketEndpoint

["Thomas Heigl (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516488#comment-17516488 ] 

Thomas Heigl commented on WICKET-6965:
--------------------------------------

[~mgrigorov]: I found on more issue with our solution for this issue while stress testing our staging environment:

{code}
ERR o.a.c.h.Http11NioProtocol Error reading request, ignored
 Apr 03 12:42:26  #011java.lang.IllegalStateExcept The WebSocket session [3] has been closed and no method (apart from close()) may be called on a closed session
 Apr 03 12:42:26  #011at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:1082)
 Apr 03 12:42:26  #011at org.apache.tomcat.websocket.WsSession.getRequestParameterMap(WsSession.java:956)
 Apr 03 12:42:26  #011at org.apache.wicket.protocol.ws.javax.WicketEndpoint.getApplicationName(WicketEndpoint.java:137)
 Apr 03 12:42:26  #011at org.apache.wicket.protocol.ws.javax.WicketEndpoint.onError(WicketEndpoint.java:114)
 Apr 03 12:42:26  #011at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.onError(WsHttpUpgradeHandler.java:234)
 Apr 03 12:42:26  #011at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:161)
 Apr 03 12:42:26  #011at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60)
 Apr 03 12:42:26  #011at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59)
 Apr 03 12:42:26  #011at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
 Apr 03 12:42:26  #011at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1743)
 Apr 03 12:42:26  #011at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 Apr 03 12:42:26  #011at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
 Apr 03 12:42:26  #011at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
 Apr 03 12:42:26  #011at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
{code}

It seems that we must not call {{getRequestParameterMap}} when an error occurs on session close. Shall we cache the application name in a field?

> Memory leak in WicketEndpoint
> -----------------------------
>
>                 Key: WICKET-6965
>                 URL: https://issues.apache.org/jira/browse/WICKET-6965
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-native-websocket
>    Affects Versions: 9.8.0
>            Reporter: Thomas Heigl
>            Assignee: Martin Tzvetanov Grigorov
>            Priority: Major
>             Fix For: 10.0.0, 8.14.0, 9.9.0
>
>         Attachments: image-2022-01-10-18-52-42-193.png, image-2022-03-21-16-27-37-798.png
>
>
> Our application OOMed yesterday after about 2-3 weeks of continuous uptime. We normally deploy every other day, so we never noticed this issue before.
> The heap dump identified the possible culprit as {{{}WicketEndpoint$ApplicationListener{}}}:
> !image-2022-01-10-18-52-42-193.png!
> Every new websocket connection registers a new instance of this application listener and after a while we ended up with millions of these listeners:
> {code:java}
> @Override
> public void onOpen(Session session, EndpointConfig endpointConfig)
> {
>     String appName = getApplicationName(session);
>     WebApplication app = (WebApplication) WebApplication.get(appName);
>     app.getApplicationListeners().add(new ApplicationListener(applicationDestroyed));
>     try
>     {
>         ThreadContext.setApplication(app);
>         javaxWebSocketProcessor = new JavaxWebSocketProcessor(session, app, endpointConfig);
>     }
>     finally
>     {
>         ThreadContext.detach();
>     }
> }
> {code}
> Instead of creating a new listener for every connection, the listener should be a singleton.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)