You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Will Sheppard <Wi...@bbc.co.uk> on 2009/05/13 17:40:59 UTC
Cocoon protocol memory leak
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.
Re: Cocoon protocol memory leak
Posted by Alexander Daniel <al...@gmx.at>.
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@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon protocol memory leak
Posted by Alexander Daniel <al...@gmx.at>.
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@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org