Message: The following issue has been re-assigned.
Assignee: Howard M. Lewis Ship (mailto:[EMAIL PROTECTED]) --------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/HIVEMIND-2 Here is an overview of the issue: --------------------------------------------------------------------- Key: HIVEMIND-2 Summary: EventListenerList leaks memory Type: Bug Status: Open Priority: Major Project: HiveMind Components: framework Versions: 1.0 Assignee: Howard M. Lewis Ship Reporter: Geoff Longman Created: Tue, 6 Apr 2004 7:24 PM Updated: Wed, 7 Apr 2004 8:19 AM Environment: jdk 1.4.1, mulitple OS's (Redhat 9, Win2k), multiple servlet containers (Jetty 4.2.8 and Tomcat 4.1.27) Description: Running a Tapestry app using Hivemind. We are getting out of memory errors after 5 to 10 minutes. There is only one user logged into the app at any one time. Built Hivemind from src in commons sandbox cvs. Using the jdk's -Xrunhprof tool. It looks like there is a memory leak in EventListener.copyOnWrite(). the raw data we are seeing... TRACE 40863: org.apache.hivemind.util.EventListenerList.copyOnWrite(EventListenerList.jav a:163) org.apache.hivemind.util.EventListenerList.removeListener(EventListenerList. java:135) org.apache.hivemind.util.EventListenerList.removeListener(EventListenerList. java:127) org.apache.hivemind.service.impl.ThreadEventNotifierImpl.removeThreadCleanup Listener(ThreadEventNotifierImpl.java:52) percent live alloc'ed stack class rank self accum bytes objs bytes objs trace name 1 80.80% 80.80% 188744400 5 377489864 89 40863 java.lang.Object The same info as above: just a bit easier to read! rank: 1 percent self: 80.80% percent accum: 80.80% live bytes: 188744400 live objs: 5 alloc's bytes: 377489864 alloc's objs: 89 stack trace: 40863 class name: java.lang.Object What follows are observations from a colleague working this problem: ----- Original Message ----- From: "Chris Justus" To: <glongman@> Sent: Tuesday, April 06, 2004 5:02 PM Subject: EventListenerList code... > Looking over the code... > > removeListener calls copyOnWrite... The problem is that if there is an > iterator when we remove a listener... > Suppose that we currently have _listeners.length with a size 5, and an > iterator ... > > (1) size = 5 > (4) nominalSize becomes 10... > (5) newSize is the max of our required size or the nominal size... so > newSize is 10... > > Call removeListener enough times, and you've got some pretty big arrays > of objects... (doubling in size every time these events occur...) > > Lines from EventListenerList.java copyOnWrite(): > ... > (1) int size = _listeners == null ? 0 : _listeners.length; > > (2) if (_iteratorCount > 0 || size < requiredSize) > (3) { > (4) int nominalSize = (size == 0) ? START_SIZE : 2 * size; > > (5) int newSize = Math.max(requiredSize, nominalSize); > > (6) Object[] newListeners = new Object[newSize]; > ... > > We're not seeing removeListener called at the end of every request on every thread in the servlet container. But, once a thread's EventListenerList starts growing, it does so for every request afterward. I did some "back of a napkin" figurin' and as the array starts at size 5 and doubles whenever removeListener is called then the array size is approx 105 million after 18 iterations. I don't know how the jdk implementation works for arrays but if each cell is a 32 bit pointer, 105 million * 4 = 420 MB. I have a test case that reproduces the error. Lets see if JIRA will let me attach it..... --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
