[ http://jira.jboss.com/jira/browse/JBMESSAGING-920?page=comments#action_12... ] Kevin Conner commented on JBMESSAGING-920: ------------------------------------------ This is from an email I sent to the ESB group earlier today. Kev ----------------------------------------------------------------------------------------------------------- - The way the current codebase repeatedly creates connections - The way JBoss Remoting works One cause appears to be the timers used by remoting. From what I can see there are three in play - ConnectionValidator - BisocketServerInvoker$ControlMonitorTimerTask - LeasePinger$LeaseTimerTask Each one of these timers has indirect access to the majority of the heap. The big culprit in the timers appears to be LeasePinger$LeaseTimerTask. When connections are closed this task is cancelled but unfortunately cancelling j.u.TimerTask does *not* remove the task from the queue, all it does is mark it as cancelled. The consequence of this is that every instance referenced by the task *cannot* be garbage collected until the timer would normally fire (and the task is then removed from the queue). Referenced from each LeasePinger instance is a BisocketClientInvoker which contains a ClientSocketWrapper. Each ClientSocketWrapper references a Socket, a DataInputStream (containing BufferedInputStream) and a DataOutputStream (containing BufferedOutputStream). Each BIS/BOS contains a 64k array! In my tests these instances amount to a cumulative size of about 1/3 of the heap. Another cause appears to be the use of hash maps. There are numerous hashmaps referenced from BisocketServerInvoker and BisocketClientInvoker which do not appear to be garbage collected. One reason is the above timers but a second is that BisocketServerInvoker holds on to BisocketServerInvoker references in a static map called listenerIdToServerInvokerMap. This map currently contains an instance of BisocketServerInvoker for every iteration of the loop. This has all been discovered from examining profile information, not source code. It may be that this analysis is completely wrong and that exmaination of the source code will highlight other issues. Kev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-920?page=comments#action_12... ] Kevin Conner commented on JBMESSAGING-920: ------------------------------------------ There were two issues found with remoting on the client side and I have now found an issue with Messaging. The ServerSessionEndpoint code contains an executor for each instance. Unfortunately nothing shuts down the executor which means that the threads created by the executor are never destroyed. I modified the messaging code to include a call to executor.shutdownNow() in ServerSessionEndpoint.close() and this appears to have done the trick. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-920?page=all ] Clebert Suconic updated JBMESSAGING-920: ---------------------------------------- Summary: Memory Leaks when opening/closing connections (was: Make sure JBM 1.2. works with ESB 4.0) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira