This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 50444 - XML Configuration Editor leak
Summary: XML Configuration Editor leak
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 4.x
Hardware: PC All
: P2 blocker (vote)
Assignee: Nam Nguyen
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 48877
  Show dependency tree
 
Reported: 2004-10-14 17:54 UTC by Chris Webster
Modified: 2005-04-04 14:22 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Webster 2004-10-14 17:54:07 UTC 
* Create j2ee project such as ejb module.
* Open sun-ejb-jar in open mode (double-click).
Make a change, save close.
* Open sun-ejb-jar in xml edit mode. Make a change
save. 
At this point there should be one instance of
ConfigurationStorage.
* open sun-ejb-jar in open mode again. 
Now you will notice two Configuration Storage
Instances. Make change save. 

Repeat this cycle and notice that
ConfigurationStorage continues to grow.
Comment 1 Petr Jiricka 2004-10-15 14:57:07 UTC 
Chris, do you know how big is this leak in terms of memory size lost?
We should set the priority accordingly. Thanks.
Comment 2 Martin Adamek 2004-10-19 08:42:58 UTC 
Profiler shows just 40 bytes leak, I decrease to P3. Nam was
interested to take this issue.
Comment 3 Chris Webster 2004-10-19 15:19:20 UTC 
Does the profiler you are using include the byte count from objects
which cannot be reclaimed because they are being referenced or just
the byte count of the object itself.
Comment 4 Martin Adamek 2004-10-19 15:37:16 UTC 
That's good point... I think it's really just object itself. I am
using Profiler Milestone 2 for NetBeans 3.6. Do you have real count?
Comment 5 Chris Webster 2004-10-19 15:58:37 UTC 
I don't have the real count either, so I had to rely on Nam's
judgement. He mentioned the transitive closure for
ConfigurationStorage is significant. The ability to determine how much
memory will be freed when an object is gc'd would be a great feature.
Comment 6 Nam Nguyen 2004-10-19 18:46:34 UTC 
In terms of size, this ConfigurationStorage leak is not significant
for Tomcat configuration, but could be large for AppServer with more
complicate graphs.  

In terms of use-cases, the test case of switch back and forth b/w open
and edit is not significant so I think its still P3.  However, the
test case of repetetive edit configuration xml-run project, would be
significant.  I would think this is P2.
Comment 7 Nam Nguyen 2004-10-23 03:00:37 UTC 
Fix checked in:
  1.23      +14 -5    
j2eeserver/src/org/netbeans/modules/j2ee/deployment/config/ConfigDataObject.java
  1.28      +46 -15   
j2eeserver/src/org/netbeans/modules/j2ee/deployment/config/ConfigurationStorage.java
  1.17      +14 -5    
j2eeserver/src/org/netbeans/modules/j2ee/deployment/config/ModuleDeploymentSupport.java