cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COCOON-1948) [Patch] Memory leak in Blocks Framework - ProcessingUtil.cleanup() does not get called
Date Wed, 08 Nov 2006 10:56:53 GMT
     [ 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

        

Mime
View raw message