DO NOT REPLY [Bug 29595] New: - Memory retention problem in XMLSecurity 1.1.0 java library

[bu...@apache.org]

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: security-dev@xml.apache.org
        ReportedBy: s_deltoro@hotmail.com


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 (s_deltoro@hotmail.com)

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 (raul-info@r-bg.com)
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.
>>