tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Mika (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TOMEE-1649) Websockets Memory Leak
Date Wed, 01 Jun 2016 10:50:59 GMT

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

Jan Mika edited comment on TOMEE-1649 at 6/1/16 10:50 AM:
----------------------------------------------------------

We tested tomee 7.0.0 and it seems that the part of the problem still persist. It is much
better but in rare cases WsSession instances are still not removed. We can simulate it only
by quick (very quick) page reopening, or quick switching (with reopening) between to pages
that use websockets. These WsSession instances are kept by WsHttpUpgradeHandler, WsFrameServer
and WsRemoteEnpointImplServer.


was (Author: jan.mika7):
We tested tomee 7.0.0 and it seems that the part of the problem still persist. It is much
better but in rare cases WsSession instances are still not removed. We can simulate it only
by quick (very quick) page reopening, or quick switching (with) reopening between to pages
that use websockets. These WsSession instances are kept by WsHttpUpgradeHandler, WsFrameServer
and WsRemoteEnpointImplServer.

> Websockets Memory Leak
> ----------------------
>
>                 Key: TOMEE-1649
>                 URL: https://issues.apache.org/jira/browse/TOMEE-1649
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 1.7.2, 1.7.3
>            Reporter: Tony Weston
>            Assignee: Romain Manni-Bucau
>            Priority: Blocker
>             Fix For: 7.0.0-M2
>
>
> Websocket sessions are not GC'd on close.  This will quickly lead to out-of-memory condition,
and server hang.  I have marked this is a blocker as any application that uses Websockets
will have this issue, and there is no workaround; it is not a corner case. 
> To reproduce, create a Websocket handler, and index.html to create the socket. See below.
  Load index.html in a browser, and refresh the page several times.
> Using VisualVM (or other memory profiler), search for websocket in the heap dump.   
You should find that every refresh of the page will cause an additional instance of WsSession,
and other supporting classes.
> These instances are referenced by org.apache.openejb.core.WebContext /  creationalContexts,
and do not appear to be removed when the websocket is closed.
> {code:title=MyWebsocket.java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.websocket.OnClose;
> import javax.websocket.OnOpen;
> import javax.websocket.Session;
> import javax.websocket.server.ServerEndpoint;
> @ServerEndpoint(value = "/ws")
> public class MyWebsocket {
> 	@OnOpen
> 	public void wsOpen(Session session){
> 		System.out.println("WS Opened");
> 	}
> 	
> 	@OnClose
> 	public void wsClosed(Session session){
> 		System.out.println("WS Closed");
> 	}
> }
> {code}
> Amend the ws://localhost:8080/WebsockMemleak/ws  url in the source below, to match your
context root / port number.
> {code:title=index.html}
> <html>
> <script>
> var ws = new WebSocket("ws://localhost:8080/WebsockMemleak/ws");
> window.onbeforeunload = function(){
> 	ws.close();
> }
> </script>
> </html>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message