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.
We need to be sure that at WCO, WebInfObject, WebClassesObject, WebAppObject and DDDataObject can be finalized. Currently the biggest problem is WebAppObject that checks for original during unmounting of web module. This check is triggeres by property change event called from WCO.setValid(false) and causes that another instance of WCO is created earlier than web module FS is unmounted. Similarly DDDataObject is created too (either as side effect of what is descirbed above or by some similar search) that register itself in ServerRegistry and never unregister because noone invalidates it.
Possible workaround for DDDataObject might be to use WeakListener but this doesn't solve the cause.
this is a good hint for 39024 and maybe also for why DataObjects remain in memory when web/core module is disabled (39095); I will have to look at this..
Another (possibly related) problem: when the web module gets disabled the link to web app remain in projects tab (not recognized by loader) and when web module is enabled again there are 2 links in projects tab. Disabling web module does not remve the link. When you unmount web module it removed one link, when you mount it again it 'reuses' one of the existing links. (unmount/mount eventually removes all links :)
I think this is fixed (Radime please verify). The cause was not in WebAppObject, as one would think, but in an inner class WebContextObject.MO that is held in memory by j2eeserver code and was holding the WebContextObject.
Now it behaves randomly in the IDE - sometimes it works well, sometimes WEB-INF/classes is left in explorer, sometimes even with 'Duplicate ...' in its name. The good news is that I have reproducible test commited into web/core/test that creates webmodule, mounts it to the repository and checks if it can be GC'ed after unmounting. This test fails always (cf. local FS mount/unmount that passes). I also tried to mount jsp-examples from Tomcat and unmount leaves classes+one of mounted JARs in repository :-( Currently I don't know what is the reason. Suspision - J2eeProfileSettings listens to server registry and never(?) deregister. It has Context that keeps the file object and this can hold whole bunch of objects - DelegatingFS, ExLocalFS, WCO + some other.
The solutio for this problem is not known, the bugfix is potentially dangerous (in that it can easilly generate regressions). The impact is limited to two cases: 1) fix amount of memory is not released after unmounting a web module 2) if there is an open web module and the jsp-servlet module is disabled the web module nodes will not be removed and user will likely get exceptions when clicking on them (this is an unlikely scenario) - the user can still unmount the file system. The web apps team agrees with waiver. The code will be removed/changed for the new build system.
I tried to run it in OptimizeIt with its memory leak detector. The test case was to mount copy of jsp-examples webapp from Tomcat 5 distro (37 JSPs, 38 Java files, 85 class files, 95 html). Only mount / unmount was perfromed w/ some delay. The bad news is that >1MB is lost with each iteration. Some details: ServerRegistry keeps J2eeProfileSettings. These have J2eeDeploymentLoopkup with DConfingBean tied to schema2beans representation of deployment descriptor. This is a lot of objects. Also (and this can be worse) J2eeProfileSettings has Context with reference to FileObject and this is probably how the whole filesystem is kept. I would like to see this fixed because the leak is too big and we should fix this problem with server registry.
Radime, thanks - this is extremely helpful. Looking into code it looks like J2eeProfileSettings is held by DeploymentTargetImpl (implements DeploymentTarget) which is held by TargetServer, ServerFileDistributor and InitialServerFileDistributor. SFD and ISFD implement ProgressObject and these are _probably_ accidently held by some UI code in j2eeserver, but I cannot see that far. This code can be cleaned up but this alone is no more then P3, IMO. I used WeakReference for J2eeProfileSettings in DeploymentTargetImpl. Can you confirm this solves the large memmory leak and downgrade to P3?
Thanks Pavel. I tried with current sources (2004-02-18 9:00 CET). IDE is run on Linux, J2SDK1.4.2_03, empty userdir, memory toolbar turned on, initialized server registry with Tomcat plugin (by expanding their nodes) and tried to mount/umount the same web module as yesterday. Here are numbers from memory toolbar that I get after GCs. Before: 10.8 1st: 12.7 2nd: 13.2 3rd: 13.7 4th: 13.9 5th: 14.5 6th: 15.1 This seems to be ~500kB per iteration. Better than before but not good yet. Some comments to solution: WeakReference may work but often it is a workaround for API deficiency. Is it the case? Sorry I am too busy too run profilers at this moment to check what is held now
Here is a bit of update: All leaks in j2eeserver for this scenario are resolved (mem diff==0 :-). The mass of memory (yes, .5M as Radim says) is still held by DD beans. The DDDataObject and related instances are held from 3 places: - WebContextObject has a listener on classesFS (DelegatingFileSystem) - DelegatingFileSystem has a FileStatusListener on WebContextObject - The cache in DDProvider (ddMap) is a weak map but it still does not release its entries because the fileobjects used a keys never get GCed All 3 need to be fixed to retake the mem and I am still strugling with the correct fixes since using WeakListeners makes the unmounting code unstable which IMO if far worse then the 500k of mem (one or more filesystems - DFS or jars - are often not unmounted - maybe 30% of time). The cache in DDProvide could probaly be written with SoftReferences which would make it possible to occasionally get cleared but that should not be a big issue (any thoughs on this, Milane?), for now I was testing by simply not putting anything into it.
I my last comment I made a wrong assumption. The listener to classesFS in WCO is actually needed and is not harmful for memory. So the fix is in making the FileStatusListener in DelegatingFileSystem weak and using weak references in the cache in DDProvider (ddMap) (besides other small fixes I made earlier in j2eeserver and web module). As for the cache in DDProvider - the keys in weak map are not GCed so it does not behave as "weak". I changed it to cache with both weak keys and values, ie. if nobody is pointing at the value (WebApp) it is OK to throw it away when there is a GC request. The practical effect of this is that DD may actually need to be parsed multiple times if nobody was using it. I am not 100% sure about the reason why the WEB-XML\xml file is never released. I susspect it may be fault of XMLDataObject which puts its non-static innerclass InfoParser into an instance of XMLReader (org.apache.crimson.parser.XMLReaderImpl) that is held in static variable of XMLDataObject. Yarda created a diff for me with static InfoParser but I do not understand the code enough to know when to release its reference to XMLDataObject or if it is ok to use WeakReference. If the modification of DDParser cache is not acceptable Milan and Jarda could possibly follow up on this. Thanks.
Sorry but the test in web/core/test still does not pass (build from Feb25). I also tried to check memeory meter but was able to repeat the test more times as there are problems w/ repeated unmounting.
Radim, how big is the memory leak now? Without this information, the priority of this issue can not be correctly assessed. Thanks.
16.1 17.5 17.7 18.1 18.1 18.2 After that I tryied to mount/unmount just the WEB-INF/classes folder several times. The numbers are staying at the same level, at the end they actually got to 17.9. But some objects are not being GCd during that so the diff is not zero. I wonder if you have a test for that? Anyway, other then the first time it is relatively insignificat amount of memmory. Note that it often takes MANY GC calls to release the memmory -- I do not know how reliable your test is in this regard. Also note that after all this testing there are no new objects from org.netbeans.modules.web.* or o.n.m.j2ee* allocated and not released in the loop. Lowering to P3, that also means the 3.6 waiver is not needed as the main problem was in deed resolved. Please provide more data if you want.
Will not be solved for 3.6. Most of the code will likely be deleted for promo-D. I am leaving the bug open to verify that.
I am closing this as fixed because there is no web module mounting in promoD