You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stuart Roebuck <st...@adolos.co.uk> on 2002/03/14 17:07:48 UTC
C2 Bug Locating Tips
+---------------------------------------------+
| LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
+---------------------------------------------+
unfortunately, I don't have a great deal of my own, but I'm happy to
compile other peoples into something useful if anyone would like to
contribute some suggestions on how I might track down an apparent memory
leak in the recent CVS versions of Cocoon!
Seeing as there is talk of... *A NEW RELEASE*...I thought it was time I
did some work on ironing this problem out now.
My setup is:
Cocoon 2 (latest CVS) - but problems have occurred for a month
or so now.
Tomcat 4.0.1
Mac OS X 10.1.3 (latest Java release) - but problems occurred
before it.
After a modest amount of Cocoon action, I get an OutOfMemoryError in the
Tomcat localhost_log (see below) and to be completely honest, I haven't
much of a clue how I'm going to track down the associated memory leak.
( which reminds me - how do you stop debug level messages )
( appearing in the Tomcat localhost_log file? Changing all )
( the references to "DEBUG" in logkit.conf turns off DEBUG )
( level output in the WEB-INF/logs directory, but not in )
( the Tomcat log directory. )
I'm now using the Pizza compiler, so the associated Javac memory leak
shouldn't be there.
I've reduced the store-janitor heapsize value from the default 67108864
to 60000000 running from a default Mac OS X Java configuration of 64Mb
max heap and this appears to delay the onset of problems.
The problems weren't present in the past, and we currently have a
pre-release site <http://www.cueandreview.co.uk/> running on an older
Cocoon 2 release which doesn't exhibit this behaviour. It's running off
a FreeBSD based machine, but it was developed without problems on Mac OS
X (with the release of Cocoon it is running on on FreeBSD).
So I'm inclined to think that the problem is something that has been
introduced in Cocoon, rather than anything platform specific or
sitemap / processing specific - but I could be wrong.
Significant things that have changed (and are being used) between the
reliable version and the current include:
Xerces 1.4.4 --> Xerces 2.0.x
TreeProcessor
JispStore
Pizza compiler
This may or may not be connected with:
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
Any thoughts, hints, suggestions?
Stuart.
> 2002-03-14 14:19:51 StandardWrapperValve[Cocoon2]: Servlet.service()
> for servlet Cocoon2 threw exception
> javax.servlet.ServletException: Servlet execution threw an exception
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:269)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:243)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:201)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke
> (AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:
> 246)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 164)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke
> (ErrorDispatcherValve.java:170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> 163)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.connector.http10.HttpProcessor.process
> (HttpProcessor.java:666)
> at
> org.apache.catalina.connector.http10.HttpProcessor.run(HttpProcessor.java:
> 788)
> at java.lang.Thread.run(Thread.java:496)
> ----- Root Cause -----
> java.lang.OutOfMemoryError
> <<no stack trace available>>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
maybe this documents are useful too:
http://xml.apache.org/cocoon/userdocs/concepts/mrustore.html
http://xml.apache.org/cocoon/userdocs/concepts/storejanitor.html
~Gerhard
----------------------------------------
"In English, there is no double positive
that makes a negative."
"Yeah, right."
----------------------------------------
>-----Original Message-----
>From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>Sent: Thursday, March 14, 2002 5:08 PM
>To: cocoon-dev@xml.apache.org
>Subject: C2 Bug Locating Tips
>
>
> +---------------------------------------------+
> | LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
> +---------------------------------------------+
>
>unfortunately, I don't have a great deal of my own, but I'm happy to
>compile other peoples into something useful if anyone would like to
>contribute some suggestions on how I might track down an apparent memory
>leak in the recent CVS versions of Cocoon!
>
>Seeing as there is talk of... *A NEW RELEASE*...I thought it was time I
>did some work on ironing this problem out now.
>
>My setup is:
> Cocoon 2 (latest CVS) - but problems have occurred for a month
>or so now.
> Tomcat 4.0.1
> Mac OS X 10.1.3 (latest Java release) - but problems occurred
>before it.
>
>After a modest amount of Cocoon action, I get an OutOfMemoryError in the
>Tomcat localhost_log (see below) and to be completely honest, I haven't
>much of a clue how I'm going to track down the associated memory leak.
>
> ( which reminds me - how do you stop debug level messages )
> ( appearing in the Tomcat localhost_log file? Changing all )
> ( the references to "DEBUG" in logkit.conf turns off DEBUG )
> ( level output in the WEB-INF/logs directory, but not in )
> ( the Tomcat log directory. )
>
>I'm now using the Pizza compiler, so the associated Javac memory leak
>shouldn't be there.
>
>I've reduced the store-janitor heapsize value from the default 67108864
>to 60000000 running from a default Mac OS X Java configuration of 64Mb
>max heap and this appears to delay the onset of problems.
>
>The problems weren't present in the past, and we currently have a
>pre-release site <http://www.cueandreview.co.uk/> running on an older
>Cocoon 2 release which doesn't exhibit this behaviour. It's running off
>a FreeBSD based machine, but it was developed without problems on Mac OS
>X (with the release of Cocoon it is running on on FreeBSD).
>
>So I'm inclined to think that the problem is something that has been
>introduced in Cocoon, rather than anything platform specific or
>sitemap / processing specific - but I could be wrong.
>
>Significant things that have changed (and are being used) between the
>reliable version and the current include:
> Xerces 1.4.4 --> Xerces 2.0.x
> TreeProcessor
> JispStore
> Pizza compiler
>
>This may or may not be connected with:
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
>
>Any thoughts, hints, suggestions?
>
>Stuart.
>
>> 2002-03-14 14:19:51 StandardWrapperValve[Cocoon2]: Servlet.service()
>> for servlet Cocoon2 threw exception
>> javax.servlet.ServletException: Servlet execution threw an exception
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java:269)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:193)
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke
>> (StandardWrapperValve.java:243)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardContextValve.invoke
>> (StandardContextValve.java:201)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke
>> (AuthenticatorBase.java:472)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:
>> 246)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
>> 164)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.valves.ErrorDispatcherValve.invoke
>> (ErrorDispatcherValve.java:170)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
>> 170)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
>> 163)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.connector.http10.HttpProcessor.process
>> (HttpProcessor.java:666)
>> at
>> org.apache.catalina.connector.http10.HttpProcessor.run(HttpProcessor.java:
>> 788)
>> at java.lang.Thread.run(Thread.java:496)
>> ----- Root Cause -----
>> java.lang.OutOfMemoryError
>> <<no stack trace available>>
>
>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
>-------------------------------------------------------------------------
>Stuart Roebuck stuart.roebuck@adolos.com
>Systems Architect Java, XML, MacOS X, XP,
>etc.
>ADOLOS <http://www.adolos.com/>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 Bug Locating Tips
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Jeremy,
Great - it's always such a relief to find someone with the same problem!
I can confirm that the problem is *not* due to the new Java update for
Mac OS X 10.1.3 - one of our test systems is still running the old
release and exhibits identical behaviour in this respect.
But Volker's recent post looks promising.
Stuart.
On Friday, March 15, 2002, at 09:41 am, Jeremy Quinn wrote:
> At 12:47 pm -0500 14/3/02, Vadim Gritsenko wrote:
>> Stuart,
>>
>> TreePorcessor is quite new thing and I'm not quite sure that anybody
>> spent time on finding memory leaks. Do you have leaks if you use
>> compiled sitemap? Try also old FS store instead of Jisp.
>>
>>
>>>> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
>>>> decommissioning instance of
>>>> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>>>
>>> Is this important?
>>
>> This one should better be answered by Sylvain.
>
>
> Yea, I too found I started getting unexpected out of memory errors
> when I
> started using the TreeProcessor.
>
> MacOSX 10.1.3 etc.
>
> It would run for ever in the Compiled sitemap with no memory errors.
>
> If this is not found on other platforms, then the recent Java update
> Apple
> made could be the culprit?
>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:47 pm -0500 14/3/02, Vadim Gritsenko wrote:
>Stuart,
>
>TreePorcessor is quite new thing and I'm not quite sure that anybody
>spent time on finding memory leaks. Do you have leaks if you use
>compiled sitemap? Try also old FS store instead of Jisp.
>
>
>> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
>> > decommissioning instance of
>> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>>
>> Is this important?
>
>This one should better be answered by Sylvain.
Yea, I too found I started getting unexpected out of memory errors when I
started using the TreeProcessor.
MacOSX 10.1.3 etc.
It would run for ever in the Compiled sitemap with no memory errors.
If this is not found on other platforms, then the recent Java update Apple
made could be the culprit?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Vadim Gritsenko <va...@verizon.net>.
Stuart,
TreePorcessor is quite new thing and I'm not quite sure that anybody
spent time on finding memory leaks. Do you have leaks if you use
compiled sitemap? Try also old FS store instead of Jisp.
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>
> Is this important?
This one should better be answered by Sylvain.
Vadim
> -----Original Message-----
> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
> Sent: Thursday, March 14, 2002 12:39 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: C2 Bug Locating Tips
>
>
> On Thursday, March 14, 2002, at 04:34 pm, Vadim Gritsenko wrote:
>
> >> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
> >>
> >> My setup is:
> >> Cocoon 2 (latest CVS) - but problems have occurred for a
> > month
> >> or so now.
> >> Tomcat 4.0.1
> >> Mac OS X 10.1.3 (latest Java release) - but problems
> > occurred
> >> before it.
> >>
> >> After a modest amount of Cocoon action, I get an OutOfMemoryError
in
> > the
> >> Tomcat localhost_log (see below) and to be completely honest, I
> > haven't
> >> much of a clue how I'm going to track down the associated memory
leak.
> >>
> >> I'm now using the Pizza compiler, so the associated Javac memory
leak
> >> shouldn't be there.
> >>
> >> I've reduced the store-janitor heapsize value from the default
> > 67108864
> >> to 60000000 running from a default Mac OS X Java configuration of
64Mb
> >> max heap and this appears to delay the onset of problems.
> >>
> >> The problems weren't present in the past, and we currently have a
> >> pre-release site <http://www.cueandreview.co.uk/> running on an
older
> >> Cocoon 2 release which doesn't exhibit this behaviour. It's
running
> > off
> >> a FreeBSD based machine, but it was developed without problems on
Mac
> > OS
> >> X (with the release of Cocoon it is running on on FreeBSD).
> >>
> >> So I'm inclined to think that the problem is something that has
been
> >> introduced in Cocoon, rather than anything platform specific or
> >> sitemap / processing specific - but I could be wrong.
> >
> > Still, for anyone to debug your leak, one has to know what
components
> > you are using. Some components could have memory leak, while others
do
> > not. So, /please provide list of used components/ :)
>
> Here goes:
>
> Generators:
> FileGenerator
> ServerPagesGenerator
> DirectoryGenerator
> RequestGenerator (not sure if we use that one at the
moment)
> ImageDirectoryGenerator
>
> Transformers:
> TraxTransformer
>
> Serializers:
> XMLSerializer
> HTMLSerializer
>
> Readers:
> ResourceReader
>
> Matchers:
> WildcardURIMatcher
> RequestParameterMatcher
> WildcardSessionAttributeMatcher
> WildcardHeaderMatcher
>
> Actions:
> DatabaseAddAction
> DatabaseDeleteAction
> DatabaseUpdateAction
> RequestParamAction
> UserAction (inhouse)
> SessionParamAction (inhouse)
>
>
> >
> >> Significant things that have changed (and are being used) between
the
> >> reliable version and the current include:
> >> Xerces 1.4.4 --> Xerces 2.0.x
> >> TreeProcessor
> >> JispStore
> >> Pizza compiler
> >>
> >> This may or may not be connected with:
> >>
> >> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
> >
> > I fail to see connection...
>
> Because I don't have much of a clue about what's going wrong I always
> think its important to refer to anything else that's not working
> properly - until I know what's wrong there might be a connection.
>
> >> Any thoughts, hints, suggestions?
> >
> > *Memory leak debugging how-to:*
> >
> > 1. Download trial of OptimizeIt
> > 2. Decrease pool sizes to the minimum
> > 3. Launch Tomcat/Cocoon
> > 4. Exercise app for a while
> > 5. Run gc several times (button on OptimizeIt's toolbar)
> > 6. Click on "mark"
> > 7. Access one URL once
> > 8. Repeat 5
> > 9. Sort by object count difference
> > 10. View allocation backtraces of the objects which count increased.
> > 11. Repeat 5-10 for all URLs.
> >
> > If everywhere you see +0 - no memory leaks found.
>
> Thanks, that looks very useful, now I've just got to persuade
OptimizeIt
> to renew my Trial - the last one ran out before I got round to trying
it!
>
> One last point - this may or may not be connected (my apologies if it
> isn't).
>
> In previous correspondence Sylvain said:
> > search for messages such as "decommissioning instance of...". This
> > reveals some undersized pools which are corrected by tuning
> > cocoon.xconf and sitemap.xmap. Undersized pools act like an object
> > factory, plus the ComponentManager overhead.
>
> I seem to recall that there was some discussion on the relative merits
> of pools over object factories for short-lived small setup objects, so
> this may not be relevent, but my sitemap log is full of entries like
> this:
>
> > DEBUG (2002-03-14) 16:58.56:617 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNodeBuild
er.
> > DEBUG (2002-03-14) 16:58.56:618 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.NamedContainerNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:619 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.MountNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:622 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.ReadNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:625 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>
> Is this important?
>
> Stuart.
>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
>
------------------------------------------------------------------------
-
> Stuart Roebuck
stuart.roebuck@adolos.com
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
<http://www.adolos.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 Bug Locating Tips
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Thursday, March 14, 2002, at 04:34 pm, Vadim Gritsenko wrote:
>> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>>
>> My setup is:
>> Cocoon 2 (latest CVS) - but problems have occurred for a
> month
>> or so now.
>> Tomcat 4.0.1
>> Mac OS X 10.1.3 (latest Java release) - but problems
> occurred
>> before it.
>>
>> After a modest amount of Cocoon action, I get an OutOfMemoryError in
> the
>> Tomcat localhost_log (see below) and to be completely honest, I
> haven't
>> much of a clue how I'm going to track down the associated memory leak.
>>
>> I'm now using the Pizza compiler, so the associated Javac memory leak
>> shouldn't be there.
>>
>> I've reduced the store-janitor heapsize value from the default
> 67108864
>> to 60000000 running from a default Mac OS X Java configuration of 64Mb
>> max heap and this appears to delay the onset of problems.
>>
>> The problems weren't present in the past, and we currently have a
>> pre-release site <http://www.cueandreview.co.uk/> running on an older
>> Cocoon 2 release which doesn't exhibit this behaviour. It's running
> off
>> a FreeBSD based machine, but it was developed without problems on Mac
> OS
>> X (with the release of Cocoon it is running on on FreeBSD).
>>
>> So I'm inclined to think that the problem is something that has been
>> introduced in Cocoon, rather than anything platform specific or
>> sitemap / processing specific - but I could be wrong.
>
> Still, for anyone to debug your leak, one has to know what components
> you are using. Some components could have memory leak, while others do
> not. So, /please provide list of used components/ :)
Here goes:
Generators:
FileGenerator
ServerPagesGenerator
DirectoryGenerator
RequestGenerator (not sure if we use that one at the moment)
ImageDirectoryGenerator
Transformers:
TraxTransformer
Serializers:
XMLSerializer
HTMLSerializer
Readers:
ResourceReader
Matchers:
WildcardURIMatcher
RequestParameterMatcher
WildcardSessionAttributeMatcher
WildcardHeaderMatcher
Actions:
DatabaseAddAction
DatabaseDeleteAction
DatabaseUpdateAction
RequestParamAction
UserAction (inhouse)
SessionParamAction (inhouse)
>
>> Significant things that have changed (and are being used) between the
>> reliable version and the current include:
>> Xerces 1.4.4 --> Xerces 2.0.x
>> TreeProcessor
>> JispStore
>> Pizza compiler
>>
>> This may or may not be connected with:
>>
>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
>
> I fail to see connection...
Because I don't have much of a clue about what's going wrong I always
think its important to refer to anything else that's not working
properly - until I know what's wrong there might be a connection.
>> Any thoughts, hints, suggestions?
>
> *Memory leak debugging how-to:*
>
> 1. Download trial of OptimizeIt
> 2. Decrease pool sizes to the minimum
> 3. Launch Tomcat/Cocoon
> 4. Exercise app for a while
> 5. Run gc several times (button on OptimizeIt's toolbar)
> 6. Click on "mark"
> 7. Access one URL once
> 8. Repeat 5
> 9. Sort by object count difference
> 10. View allocation backtraces of the objects which count increased.
> 11. Repeat 5-10 for all URLs.
>
> If everywhere you see +0 - no memory leaks found.
Thanks, that looks very useful, now I've just got to persuade OptimizeIt
to renew my Trial - the last one ran out before I got round to trying it!
One last point - this may or may not be connected (my apologies if it
isn't).
In previous correspondence Sylvain said:
> search for messages such as "decommissioning instance of...". This
> reveals some undersized pools which are corrected by tuning
> cocoon.xconf and sitemap.xmap. Undersized pools act like an object
> factory, plus the ComponentManager overhead.
I seem to recall that there was some discussion on the relative merits
of pools over object factories for short-lived small setup objects, so
this may not be relevent, but my sitemap log is full of entries like
this:
> DEBUG (2002-03-14) 16:58.56:617 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:618 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.NamedContainerNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:619 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.MountNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:622 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ReadNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:625 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
Is this important?
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>
> +---------------------------------------------+
> | LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
> +---------------------------------------------+
>
> unfortunately, I don't have a great deal of my own, but I'm happy to
> compile other peoples into something useful if anyone would like to
> contribute some suggestions on how I might track down an apparent
memory
> leak in the recent CVS versions of Cocoon!
>
> Seeing as there is talk of... *A NEW RELEASE*...I thought it was time
I
> did some work on ironing this problem out now.
>
> My setup is:
> Cocoon 2 (latest CVS) - but problems have occurred for a
month
> or so now.
> Tomcat 4.0.1
> Mac OS X 10.1.3 (latest Java release) - but problems
occurred
> before it.
>
> After a modest amount of Cocoon action, I get an OutOfMemoryError in
the
> Tomcat localhost_log (see below) and to be completely honest, I
haven't
> much of a clue how I'm going to track down the associated memory leak.
>
> ( which reminds me - how do you stop debug level messages )
> ( appearing in the Tomcat localhost_log file? Changing all )
> ( the references to "DEBUG" in logkit.conf turns off DEBUG )
> ( level output in the WEB-INF/logs directory, but not in )
> ( the Tomcat log directory. )
>
> I'm now using the Pizza compiler, so the associated Javac memory leak
> shouldn't be there.
>
> I've reduced the store-janitor heapsize value from the default
67108864
> to 60000000 running from a default Mac OS X Java configuration of 64Mb
> max heap and this appears to delay the onset of problems.
>
> The problems weren't present in the past, and we currently have a
> pre-release site <http://www.cueandreview.co.uk/> running on an older
> Cocoon 2 release which doesn't exhibit this behaviour. It's running
off
> a FreeBSD based machine, but it was developed without problems on Mac
OS
> X (with the release of Cocoon it is running on on FreeBSD).
>
> So I'm inclined to think that the problem is something that has been
> introduced in Cocoon, rather than anything platform specific or
> sitemap / processing specific - but I could be wrong.
Still, for anyone to debug your leak, one has to know what components
you are using. Some components could have memory leak, while others do
not. So, /please provide list of used components/ :)
> Significant things that have changed (and are being used) between the
> reliable version and the current include:
> Xerces 1.4.4 --> Xerces 2.0.x
> TreeProcessor
> JispStore
> Pizza compiler
>
> This may or may not be connected with:
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
I fail to see connection...
> Any thoughts, hints, suggestions?
*Memory leak debugging how-to:*
1. Download trial of OptimizeIt
2. Decrease pool sizes to the minimum
3. Launch Tomcat/Cocoon
4. Exercise app for a while
5. Run gc several times (button on OptimizeIt's toolbar)
6. Click on "mark"
7. Access one URL once
8. Repeat 5
9. Sort by object count difference
10. View allocation backtraces of the objects which count increased.
11. Repeat 5-10 for all URLs.
If everywhere you see +0 - no memory leaks found.
Vadim
> Stuart.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org