[ http://issues.apache.org/jira/browse/COCOON-1948?page=all ]
Alexander Klimetschek updated COCOON-1948:
------------------------------------------
Attachment: cocoon-blocks-fw-fix-memory-leak.patch
This patch
- adds the cleanup() call to the DispatcherServlet
- an outputstream close() call in the BlockConnection
- implements flush() (used) and close() (not used in my testings, but for
consistency) methods in the BlockCallHttpServletResponse.getOutputStream()
anonymous class
To be applied in root of cocoon trunk. Affects the modules cocoon-core and
cocoon-blocks-fw-impl.
> [Patch] Memory leak in Blocks Framework - ProcessingUtil.cleanup() does not
> get called
> --------------------------------------------------------------------------------------
>
> Key: COCOON-1948
> URL: http://issues.apache.org/jira/browse/COCOON-1948
> Project: Cocoon
> Issue Type: Bug
> Components: - Blocks Framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Alexander Klimetschek
> Priority: Critical
> Attachments: cocoon-blocks-fw-fix-memory-leak.patch
>
>
> ProcessingUtil.cleanup() does not get called when using the blocks framework.
> Thus all components stay in memory, including references to OutputStreams
> (mostly via the ResourceReader, depending on the actual sitemaps), so the
> heap quickly grows to its maximum.
> The ProcessingUtil.cleanup() call cannot be put into the
> sitemap.SitemapServlet because it cleans everything, including the current
> request data, so when called in a block that is called by another block, upon
> return no further processing is possible because you get NPEs when accessing
> the original HttpRequest...
> So I put that call into the DispatcherServlet, right at the end of the
> service() method and it seems to work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
