DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29595>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29595 Memory retention problem in XMLSecurity 1.1.0 java library Summary: Memory retention problem in XMLSecurity 1.1.0 java library Product: Security Version: unspecified Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Signature AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A memory retention problem has been detected in the org.apache.xml.security.utils.IdResolver class. The reason lies inside the method "public static void registerElementById (Element element, String idValue)", specifically in this line: >> elementMap.put(idValue, element); >> This instruction adds elements to a WeakHashMap using "strong" references, not "weak" references (please see http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html for details). (These elements contain xerces DeferredDocumentImpl objects). The JVM's garbage collector will automatically remove from the memory heap all the objects referenced "weakly" that are no longer used, but not the objects referenced "strongly". Therefore, this instruction provokes that the gc cannot remove all objects from memory, so each invocation to the IdResolver class leaves new objects in the heap that cannot removed after use. The result is that the heap consumption grows constantly until the maximum configured for the JVM, making the performance degrade more and more. After discussion in the developers mail list, two solving approaches have been proposed: 1) Proposed by Salvador Deltoro ([EMAIL PROTECTED]) We have developed locally a patch in order to solve this issue that has worked perfectly well under performance testing. I have substituted the former instruction by this one: >> elementMap.put(idValue, new java.lang.ref.WeakReference(element)); >> In this way, the IdResolver class puts the element as a explicit "weak" reference, so the garbage collector can remove it when no longer 2) Proposed by Raúl Benito ([EMAIL PROTECTED]) quoting his mail 3rd june 2004... >> This is exactly what is happening in one call path, see this code XMLSignature(but the same code is Manifest,Reference, and several others) /** * Sets the <code>Id</code> attribute * * @param Id Id value to be used by the id attribute on the Signature Element */ public void setId(String Id) { if ((this._state == MODE_SIGN) && (Id != null)) { this._constructionElement.setAttributeNS(null, Constants._ATT_ID, Id); IdResolver.registerElementById(this._constructionElement, Id); } } If you see when the setId is called it is called the Key is referenced by the value in a hard way. We can modify the put or we can modify this call but it seams a memory leak that needs to be fixed. >>
