cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: C2 Bug Locating Tips
Date Thu, 14 Mar 2002 17:39:11 GMT

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


Mime
View raw message