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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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.
