DO NOT REPLY [Bug 27764] New: - DefaultIncludeCacheManager does not release xml-serializer under some circumstances

[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=27764>.
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=27764

DefaultIncludeCacheManager does not release xml-serializer under some circumstances

           Summary: DefaultIncludeCacheManager does not release xml-
                    serializer under some circumstances
           Product: Cocoon 2
           Version: 2.1.4
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: core
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: cmoss@tvnz.co.nz


Currently the only reproducable test case I have for this is with the non 
parallel caching CIncludeTransformer, however I suspect that the same will 
happen for parallel caching:

The method "stream" within DefaultIncludeCacheManager does not release the xml-
serializer it uses. The code here:

                   serializer = (XMLSerializer)this.manager.lookup
(XMLSerializer.ROLE);
                   XMLTeePipe tee = new XMLTeePipe(handler, serializer);
                   
                   SourceUtil.toSAX(source, tee);
                   
                   SourceValidity[] validities = new SourceValidity[1];
                   validities[0] = session.getExpiresValidity();
                   CachedResponse response = new CachedResponse(validities,
                                                                (byte[])
serializer.getSAXFragment());
                   session.getCacheStorageProxy().put(uri, response);


Never releases the serializer.  This means that a cocoon instance with many 
instances of caching cincludes will soon exhibit a huge number of unused (and 
unsable) xml-serializers.   If the max-pool is not strict for the xml-
serializer component this will result in fairly rapid increase in irrecoverable 
memory usage - trust me on this one ;)

I suspect that the parallel branch of this method will also suffer from this 
problem, but I've not yet investigated - maybe someone using the background 
caching can?

The fix for this is of course very simple, I'll attach a patch.