Cocoon protocol memory leak

[Will Sheppard]

We have a sitemap where a calls b, which calls c, which calls d (see below). The reason it's set up like this is so we can view each stage on its own, to facilitate development and debugging.

We were noticing massive memory leakage. If the a/*/* pipeline was hit 200 times, the memory usage would shoot up to 200Mb and never come down, even after garbage collection had run.

After we replaced all the ‘cocoon:’ protocol calls with 'http://localhost/path/to/cocoon', the memory leak disappeared. No matter how many times or how fast the pipeline was hit, memory usage would always come down just before it reached 100Mb. It would stabilise at around 40-50Mb after garbage collection. We only made that one change to the sitemap.

But we'd really like to use the cocoon: protocol, so that the error stack is followed properly upon errors (among other reasons). When using the 'localhost' method, the stack trace stops at the last URL accessed.

Has anyone encountered an issue like this memory leak, or knows of a solution?

We are using Cocoon 2.2 under JBoss 4.2.2 on 64-bit Linux.
Original sitemap follows. Filenames, etc. have been changed.

<map:match pattern="a/*/*">
    <map:generate src="cocoon:/b/{1}/{2}" />
    <map:transform src="r/x.xsl" type="saxon" />
    <map:serialize type="xml" />
</map:match>

<map:match pattern="b/*/*">
    <map:generate src="cocoon:/c/{1}/{2}" />
    <map:transform type="sql">
        <map:parameter name="use-connection" value="r" />
    </map:transform>
    <map:serialize type="xml" />
</map:match>

<map:match pattern="c/*/*">
    <map:act type="request">
        <map:parameter name="parameters" value="true"/>
        <map:generate src="cocoon:/d/{../1}" />
        <map:transform src="r/y.xsl" type="saxon"/>
        <map:transform type="cinclude" />
        <map:transform src="r/z.xsl" type="saxon"/>
    </map:act>
    <map:serialize type="xml" />
</map:match>

<map:match pattern="d/*">
    <map:generate src="r/t.xml" />
    <map:transform src="r/s.xsl" type="saxon">
        <map:parameter name="resource" value="{1}" />
    </map:transform>
    <map:serialize type="xml" />
</map:match>


Will



http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

[Alexander Daniel]

Thanks for sharing your observations. This might be related to a  
problem we are currently facing.

The use of the cocoon: protocol has several other pros additional to  
error stack:
- caching
- map:generate in caller and map:serialize in callee will be optimized  
and the SAX stream is passed on [1]

Alex

[1] http://www.peachpit.com/articles/article.aspx?p=30037&seqNum=1 and  
search for "event pipeline"

On 13.05.2009, at 17:40, Will Sheppard wrote:

> We have a sitemap where a calls b, which calls c, which calls d (see  
> below). The reason it's set up like this is so we can view each  
> stage on its own, to facilitate development and debugging.
>
> We were noticing massive memory leakage. If the a/*/* pipeline was  
> hit 200 times, the memory usage would shoot up to 200Mb and never  
> come down, even after garbage collection had run.
>
> After we replaced all the ‘cocoon:’ protocol calls with 'http://localhost/path/to/cocoon' 
> , the memory leak disappeared. No matter how many times or how fast  
> the pipeline was hit, memory usage would always come down just  
> before it reached 100Mb. It would stabilise at around 40-50Mb after  
> garbage collection. We only made that one change to the sitemap.
>
> But we'd really like to use the cocoon: protocol, so that the error  
> stack is followed properly upon errors (among other reasons). When  
> using the 'localhost' method, the stack trace stops at the last URL  
> accessed.
>
> Has anyone encountered an issue like this memory leak, or knows of a  
> solution?
>
> We are using Cocoon 2.2 under JBoss 4.2.2 on 64-bit Linux.
> Original sitemap follows. Filenames, etc. have been changed.
>
> <map:match pattern="a/*/*">
>     <map:generate src="cocoon:/b/{1}/{2}" />
>     <map:transform src="r/x.xsl" type="saxon" />
>     <map:serialize type="xml" />
> </map:match>
>
> <map:match pattern="b/*/*">
>     <map:generate src="cocoon:/c/{1}/{2}" />
>     <map:transform type="sql">
>         <map:parameter name="use-connection" value="r" />
>     </map:transform>
>     <map:serialize type="xml" />
> </map:match>
>
> <map:match pattern="c/*/*">
>     <map:act type="request">
>         <map:parameter name="parameters" value="true"/>
>         <map:generate src="cocoon:/d/{../1}" />
>         <map:transform src="r/y.xsl" type="saxon"/>
>         <map:transform type="cinclude" />
>         <map:transform src="r/z.xsl" type="saxon"/>
>     </map:act>
>     <map:serialize type="xml" />
> </map:match>
>
> <map:match pattern="d/*">
>     <map:generate src="r/t.xml" />
>     <map:transform src="r/s.xsl" type="saxon">
>         <map:parameter name="resource" value="{1}" />
>     </map:transform>
>     <map:serialize type="xml" />
> </map:match>
>
>
> Will
>
>
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain  
> personal views which are not the views of the BBC unless  
> specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in  
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Alexander Daniel]

On 13.05.2009, at 17:40, Will Sheppard wrote:

> After we replaced all the ‘cocoon:’ protocol calls with 'http://localhost/path/to/cocoon' 
> , the memory leak disappeared. No matter how many times or how fast  
> the pipeline was hit, memory usage would always come down just  
> before it reached 100Mb. It would stabilise at around 40-50Mb after  
> garbage collection. We only made that one change to the sitemap.
>
> But we'd really like to use the cocoon: protocol, so that the error  
> stack is followed properly upon errors (among other reasons). When  
> using the 'localhost' method, the stack trace stops at the last URL  
> accessed.
>
> Has anyone encountered an issue like this memory leak, or knows of a  
> solution?
>
> We are using Cocoon 2.2 under JBoss 4.2.2 on 64-bit Linux.

I also encountered the issue and fortunately after many days browsing  
through jhat heap dumps [1] and debugging Cocoon I found a solution: https://issues.apache.org/jira/browse/COCOON-2259

Please let us know if it fixes your memory leak.

Have fun, Alex

[1] http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...