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.
There seems to be a cumulative memory leak in the objects stored in the RaveRenderedDocument.userData table. RaveSourceDocument, FacesDesignBean, DesignBeanNode, etc. leak from this table. To reproduce: 1) Create a VW project 2) Drop a button component on Page1 3) Deploy 4) Delete the button component. 5) Deploy 6) Repeat steps 2-4 Memory usage gradually increases with each deployment (which forces a FacesModel.sync() operation).
The step 6 should be "Repeat steps 2-5".
There is a link from rendered document to source document. The link seems to be, is not removed, and should be made weak. I'm going to look at that.
Well, now I was thinking about it, and the previous comments don't sound correct. This seems to be about accumulating link to the DesignBeanNode (or DesignBean). Need to investigate.
So far discovered one leak in DnDHandler, recentDropTargetComponentRootElement field. Going to fix that one first. Didn't discover leak in the RaveRenderedDocument user data yet, it doesn't hold the RaveSourceDocument there (not directly), the link is maintained by the FacesModel(MarkupUnit). Will continue after finish the above fix.
Yes, it seems the problem is impl of the org.w3c.dom.Document.userData... it is implemented by HashTable, and it seems that it doesn't clear it for elements which are removed from the document.
Also problem is that the UserDataHandler.handle methods don't seem to get called (especially when removed the elements).
Well, it seems that the userData impl of the apache dom Document leak, and there doesn't seem to be a way to fix it from our subclass. Thinking about, whether to avoid usage of the userData, and rather maintain individual maps.
To clear up the things, it is not RaveRenderedDocument.userData field (there is no such), but CoreDocumentImpl.userData field.
Fixed. Note, there are also other usages of userData, which I need to get rid of, but those shouldn't affect this issue. Checking in visualweb/insync/src/org/netbeans/modules/visualweb/insync/markup/MarkupUnit.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/markup/MarkupUnit.java,v <-- MarkupUnit.java new revision: 1.10; previous revision: 1.9 done
The memory leak still occurs from RaveRenderedDocument->RaveSourceDocument. To reproduce: 1) Create vw project 2) Drop some component onto Page1.jsp 3) Clean-Build 4) Remove some components from the page or drop additional ones 5) Repeat 3-4
Quy, are you saying in that case there is more than 1 source or more than 1 rendered document left? I didn't experience such before, there was always 1 source and 1 rendered doc, as it should. I am going to try out your case.
I see 1 RaveRenderedDocument that holds onto multiple RaveSourceDocument objects.
Another method to reproduce: 1) Create a vw project 2) Drop a button component 3) Switch to JSP view 4) Make a modification (I changed the button's text attribute value) 5) Switch back to Design view 6) Repeat steps 3-5 This looks like it leaks a RaveSourceDocument object every time steps 3-5 are done.
I checked the later example, and the leak is not caused by RaveRenderedDocument, there is no direct link from it to the RaveSourceDocument. The one rather seems to be leaking by FacesBean, or LiveUnit (listeners?) or FacesModel. Also there were 5 FacesModel instances but designer/jsf had correctly only one JsfForm. Those last cases seem to belong to insync, passing there.
"Also there were 5 FacesModel instances but designer/jsf had correctly only one JsfForm." Depends on how many pages and request, session and application beans you have. There is one FacesModel for one Page. There is one JsfForm for one Page. However the other 3 FacesModels are for RequestBean1, sessionBeans1 and ApplicationBeans1 assuming a normal project. So one additional FacesModel needs explanation. Do you have more than one page or page fragment? Quy, can you add some more details of the GCRoot paths.
Assigning back to Peter: RaveRenderedDocument->hashtable->entry->value->hashtable->.....->RaveSourceDocument links.
Yes, it is there, it is needed to add, that the navigator window needs to be closed when proceeding the last case.
Fixed. After this additional patch, the last case seems to be working now. Checking in visualweb/designer/markup/src/org/netbeans/modules/visualweb/designer/markup/MarkupServiceImpl.java; /cvs/visualweb/designer/markup/src/org/netbeans/modules/visualweb/designer/markup/MarkupServiceImpl.java,v <-- MarkupServiceImpl.java new revision: 1.16; previous revision: 1.15 done