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 2001/08/01 19:30:19 UTC
[C2] Possible bug in SitemapComponentSelector.select() ?
Trying hard to debug things without having to understand all the ins and
outs of Avalon and Cocoon, I think I may have tracked problems down to
something.
In SitemapComponentSelector.java, the select method is as follows:
> public Component select(Object hint) throws ComponentException {
> Component component = null;
>
> try {
> component = super.select(hint);
> } catch (ComponentException ce) {
> if (this.parentSelector != null) {
> component = this.parentSelector.select(hint);
> } else {
> throw ce;
> }
> }
>
> return component;
> }
this.parentSelector.select(hint) is called if super.select(hint) throws a
ComponentException, but if super.select() is using a
PoolableComponentHandler, it is going to prefer to expand its pool than
return with an exception, so the second call is not going to happen.
Now I really haven't had time to get my head round what parents are and
what the difference is between a Handler a Manager a Factory, etc., but if
I'm guessing correctly, then may be this means that in a sitemap situation
like:
> <map:match pattern="news-*.html">
> <map:aggregate element="aggregate">
> <map:part src="cocoon:/general_info.xml" element="general" />
> <map:part src="cocoon:/select/news/{1}.xml" element="news" />
> <!-- <map:part src="cocoon:/images-news.xml" element="images-news"
> /> -->
> </map:aggregate>
> <map:transform src="transform/specific/prepare_news_page.xslt" />
> <map:transform src="transform/general/docbook_article.xslt" />
> <map:transform src="transform/specific/site_look.xslt" />
> <map:serialize/>
> </map:match>
...
> <map:match pattern="select/*/*.xml">
> <map:generate type="serverpages"
> src="cocoon:/create-data_select_xsp/{1}.xml">
> <map:parameter name="idtext" value="{2}" />
> </map:generate>
> <map:serialize type="xml" />
> </map:match>
>
A request for "new-test_news.html" is going to request
"cocoon:/select/news/test_news.xml" which, during its processing is going
to look for JaxpTransformer components from its own pool before that of
its parent. Consequently, on every call it is going to create a whole new
pool and set of transformers.
I really am guessing a lot here, and my terminology is probably all wrong,
but I'm really keen to sort this one out!
Here's a stack dump of an occurence of this issue corresponding to the
example above. The stack dump is not due to any error, its just a dump on
entry to the JaxpParser.newDocument() call:
> [1] org.apache.cocoon.components.parser.JaxpParser.newDocument
> (JaxpParser.java:79)
> [2]
> org.apache.cocoon.components.browser.BrowserImpl.createDocumentForBrowserInfo
> (BrowserImpl.java:393)
> [3] org.apache.cocoon.components.browser.BrowserImpl.compose
> (BrowserImpl.java:156)
> [4]
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance
> (DefaultComponentFactory.java:98)
> [5] org.apache.avalon.excalibur.component.DefaultComponentHandler.get
> (DefaultComponentHandler.java:92)
> [6]
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup
> (ExcaliburComponentManager.java:266)
> [7]
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup
> (ExcaliburComponentManager.java:223)
> [8] org.apache.cocoon.transformation.TraxTransformer.compose
> (TraxTransformer.java:334)
> [9]
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance
> (DefaultComponentFactory.java:98)
> [10] org.apache.avalon.excalibur.pool.AbstractPool.newPoolable
> (AbstractPool.java:70)
> [11] org.apache.avalon.excalibur.pool.SoftResourceLimitingPool.grow
> (SoftResourceLimitingPool.java:82)
> [12] org.apache.avalon.excalibur.pool.DefaultPool.get (DefaultPool.java:
> 125)
> [13] org.apache.avalon.excalibur.component.PoolableComponentHandler.get
> (PoolableComponentHandler.java:117)
> [14]
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select
> (ExcaliburComponentSelector.java:246)
> [15] org.apache.cocoon.sitemap.SitemapComponentSelector.select
> (SitemapComponentSelector.java:49)
> [16]
> org.apache.cocoon.components.pipeline.AbstractEventPipeline.addTransformer
> (AbstractEventPipeline.java:95)
> [17]
> org.apache.cocoon.components.pipeline.CachingEventPipeline.addTransformer
> (CachingEventPipeline.java:93)
> [18] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.wildcardMatchN334
> (sitemap_xmap.java:3108)
> [19] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.process (sitemap_xmap.java:
> 1467)
> [20] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.process (sitemap_xmap.java:
> 1346)
> [21] org.apache.cocoon.components.source.SitemapSource.refresh
> (SitemapSource.java:247)
> [22] org.apache.cocoon.components.source.SitemapSource.<init>
> (SitemapSource.java:145)
> [23] org.apache.cocoon.components.source.CocoonSourceFactory.getSource
> (CocoonSourceFactory.java:53)
> [24] org.apache.cocoon.components.source.SourceHandlerImpl.getSource
> (SourceHandlerImpl.java:132)
> [25] org.apache.cocoon.environment.AbstractEnvironment.resolve
> (AbstractEnvironment.java:229)
> [26] org.apache.cocoon.environment.wrapper.EnvironmentWrapper.resolve
> (EnvironmentWrapper.java:222)
> [27]
> org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load
> (ProgramGeneratorImpl.java:141)
> [28] org.apache.cocoon.generation.ServerPagesGenerator.setup
> (ServerPagesGenerator.java:153)
> [29]
> org.apache.cocoon.components.pipeline.AbstractEventPipeline.setupPipeline
> (AbstractEventPipeline.java:146)
> [30] org.apache.cocoon.components.pipeline.CachingEventPipeline.setup
> (CachingEventPipeline.java:246)
> [31]
> org.apache.cocoon.components.pipeline.CachingEventPipeline.generateKey
> (CachingEventPipeline.java:108)
> [32] org.apache.cocoon.components.source.SitemapSource.refresh
> (SitemapSource.java:259)
> [33] org.apache.cocoon.components.source.SitemapSource.<init>
> (SitemapSource.java:145)
> [34] org.apache.cocoon.components.source.CocoonSourceFactory.getSource
> (CocoonSourceFactory.java:53)
> [35] org.apache.cocoon.components.source.SourceHandlerImpl.getSource
> (SourceHandlerImpl.java:132)
> [36] org.apache.cocoon.environment.AbstractEnvironment.resolve
> (AbstractEnvironment.java:229)
> [37] org.apache.cocoon.sitemap.ContentAggregator.setup
> (ContentAggregator.java:284)
> [38]
> org.apache.cocoon.components.pipeline.AbstractEventPipeline.setupPipeline
> (AbstractEventPipeline.java:146)
> [39] org.apache.cocoon.components.pipeline.CachingEventPipeline.setup
> (CachingEventPipeline.java:246)
> [40]
> org.apache.cocoon.components.pipeline.CachingEventPipeline.generateKey
> (CachingEventPipeline.java:108)
> [41]
> org.apache.cocoon.components.pipeline.CachingStreamPipeline.process
> (CachingStreamPipeline.java:279)
> [42] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.wildcardMatchN1DD
> (sitemap_xmap.java:2057)
> [43] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.process (sitemap_xmap.java:
> 1387)
> [44] org.apache.cocoon.www.file_.Users.stuart.Documents.Clients.Adolos.
> Adolos_Website.Development.webapp.sitemap_xmap.process (sitemap_xmap.java:
> 1330)
> [45] org.apache.cocoon.sitemap.Handler.process (Handler.java:160)
> [46] org.apache.cocoon.sitemap.Manager.invoke (Manager.java:103)
> [47] org.apache.cocoon.Cocoon.process (Cocoon.java:423)
> [48] org.apache.cocoon.servlet.CocoonServlet.service
> (CocoonServlet.java:507)
> [49] javax.servlet.http.HttpServlet.service (HttpServlet.java:853)
> [50] org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:247)
> [51] org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:193)
> [52] org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:243)
> [53] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:566)
> [54] org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.
> java:472)
> [55] org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:
> 943)
> [56] org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:219)
> [57] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:566)
> [58] org.apache.catalina.valves.CertificatesValve.invoke
> (CertificatesValve.java:246)
> [59] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:564)
> [60] org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.
> java:472)
> [61] org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:
> 943)
> [62] org.apache.catalina.core.StandardContext.invoke
> (StandardContext.java:2251)
> [63] org.apache.catalina.core.StandardHostValve.invoke
> (StandardHostValve.java:164)
> [64] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:566)
> [65] org.apache.catalina.valves.AccessLogValve.invoke
> (AccessLogValve.java:446)
> [66] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:564)
> [67] org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.
> java:472)
> [68] org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:
> 943)
> [69] org.apache.catalina.core.StandardEngineValve.invoke
> (StandardEngineValve.java:163)
> [70] org.apache.catalina.core.StandardPipeline.invokeNext
> (StandardPipeline.java:566)
> [71] org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.
> java:472)
> [72] org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:
> 943)
> [73] org.apache.catalina.connector.http.HttpProcessor.process
> (HttpProcessor.java:984)
> [74] org.apache.catalina.connector.http.HttpProcessor.run
> (HttpProcessor.java:1074)
> [75] java.lang.Thread.run (Thread.java:496)
Thoughts?
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer 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] Possible bug in SitemapComponentSelector.select() ?
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Okay, at last I think I've fixed this problem. Thank you Vadim for making
me aware that components could have individual pool settings. Many days
later and many false leads past I now have a ridiculously simple solution.
I think it would be a very helpful idea to include at least one use of
these individual component pooling settings in the example sitemap just to
let people know the facility is there.
All I needed to do was set:
> <stream-pipeline
> class="org.apache.cocoon.components.pipeline.CachingStreamPipeline"
> pool-max="32" pool-min="16" pool-grow="4" />
and
> <event-pipeline
> class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
> max="32" pool-min="16" pool-grow="4" />
in my cocoon.xconf file, and:
> <map:generator name="file"
> src="org.apache.cocoon.generation.FileGenerator" label="content" max="32"
> pool-min="16" pool-grow="4" />
and
> <map:transformer name="xslt"
> src="org.apache.cocoon.transformation.TraxTransformer" pool-max="32"
> pool-min="16" pool-grow="4">
and
> <map:serializer name="xml" mime-type="text/xml"
> src="org.apache.cocoon.serialization.XMLSerializer" pool-max="32"
> pool-min="16" pool-grow="4"/>
in my sitemap.xmap file.
and this made a big difference. Last weeks 6.4 secs is down to todays 100
ms.
I'm still a little purplexed as to why every new TraxTransformer was
creating 8 new JaxpParsers - this still seems like some kind of
inefficiency to me, but I'll have to leave it be for the moment.
Stuart.
On Wednesday, August 1, 2001, at 11:08 pm, Stuart Roebuck wrote:
> Vadim,
>
> Thanks, a much appreciated suggestion - I'll try that tomorrow.
>
> Stuart.
>
> On Wednesday, August 1, 2001, at 10:01 pm, Vadim Gritsenko wrote:
>
>>> know it a lot better than me; if the second then please let me know so
>>> that I know it's worth pursuing.
>>>
>>> I do know that something is causing requests for the same page to create
>>> 16 new JaxpParser components on every invocation,
>>
>> Check pool size (add some debug info into SoftResourceLimitingPool.java)
>> .
>> If it's always growing, on every request, up to enormous size, then it's
>> clear that
>> components are not released properly somewhere. If it's growing and
>> shrinking - it
>> just means that you need to define bigger pool for this component kind
>> (xslt in your
>> case).
>>
>> Vadim
>>
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer 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] Possible bug in SitemapComponentSelector.select() ?
Posted by "Stuart Roebuck (BlueYonder)" <st...@mac.com>.
Vadim,
Thanks, a much appreciated suggestion - I'll try that tomorrow.
Stuart.
On Wednesday, August 1, 2001, at 10:01 pm, Vadim Gritsenko wrote:
>> know it a lot better than me; if the second then please let me know so
>> that I know it's worth pursuing.
>>
>> I do know that something is causing requests for the same page to create
>> 16 new JaxpParser components on every invocation,
>
> Check pool size (add some debug info into SoftResourceLimitingPool.java).
> If it's always growing, on every request, up to enormous size, then it's
> clear that
> components are not released properly somewhere. If it's growing and
> shrinking - it
> just means that you need to define bigger pool for this component kind
> (xslt in your
> case).
>
> Vadim
>
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer 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] Possible bug in SitemapComponentSelector.select() ?
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Stuart Roebuck [mailto:stuartroebuck@mac.com (BlueYonder)]
> Sent: Wednesday, August 01, 2001 4:08 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [C2] Possible bug in SitemapComponentSelector.select() ?
>
>
>
> On Wednesday, August 1, 2001, at 08:10 pm, Vadim Gritsenko wrote:
>
> > Stuart,
> >
> > </snip>
> >
> >>
> >> A request for "new-test_news.html" is going to request
> >> "cocoon:/select/news/test_news.xml" which, during its processing is going
> >> to look for JaxpTransformer components from its own pool before that of
> >> its parent. Consequently, on every call it is going to create a whole
> >> new
> >> pool and set of transformers.
> >
> > SitemapComponentSelectors (and their pools) are created once during
> > initialization
> > of (sub)sitemap, and parent is set to appropriate
> > SitemapComponentSelector from the
> > parent sitemap (or Cocoon itself for main sitemap), see
> > AbstractSitemap.compose() method.
> >
> > When looking for component, first component from this sitemap is looked
> > up. If none found,
> > selector attempts to get component from parent.
> >
> > Are you able to reproduce your problem on Cocoon's example sitemap?
>
> I can't quite tell from your response whether you are proving me wrong or
> encouraging me to investigate this further. If the first then your
> probably right, blind debugging of totally unfamiliar code isn't easy
> (particularly when it is practically undocumented) and you sound like you
I'm just trying to say that "whole new pool and set of transformers" must
NEVER be created on every call. They must be initalized once, during sitemap
loading - and this is done in sitemap_xmap.configure() and AbstractSitemap.compose().
> know it a lot better than me; if the second then please let me know so
> that I know it's worth pursuing.
>
> I do know that something is causing requests for the same page to create
> 16 new JaxpParser components on every invocation,
Check pool size (add some debug info into SoftResourceLimitingPool.java).
If it's always growing, on every request, up to enormous size, then it's clear that
components are not released properly somewhere. If it's growing and shrinking - it
just means that you need to define bigger pool for this component kind (xslt in your
case).
Vadim
> and my posts are an
> attempt to move toward finding a solution.
>
> Stuart.
>
> -------------------------------------------------------------------------
> Stuart Roebuck stuart.roebuck@adolos.com
> Lead Developer 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] Possible bug in SitemapComponentSelector.select() ?
Posted by "Stuart Roebuck (BlueYonder)" <st...@mac.com>.
On Wednesday, August 1, 2001, at 08:10 pm, Vadim Gritsenko wrote:
> Stuart,
>
> </snip>
>
>>
>> A request for "new-test_news.html" is going to request
>> "cocoon:/select/news/test_news.xml" which, during its processing is going
>> to look for JaxpTransformer components from its own pool before that of
>> its parent. Consequently, on every call it is going to create a whole
>> new
>> pool and set of transformers.
>
> SitemapComponentSelectors (and their pools) are created once during
> initialization
> of (sub)sitemap, and parent is set to appropriate
> SitemapComponentSelector from the
> parent sitemap (or Cocoon itself for main sitemap), see
> AbstractSitemap.compose() method.
>
> When looking for component, first component from this sitemap is looked
> up. If none found,
> selector attempts to get component from parent.
>
> Are you able to reproduce your problem on Cocoon's example sitemap?
I can't quite tell from your response whether you are proving me wrong or
encouraging me to investigate this further. If the first then your
probably right, blind debugging of totally unfamiliar code isn't easy
(particularly when it is practically undocumented) and you sound like you
know it a lot better than me; if the second then please let me know so
that I know it's worth pursuing.
I do know that something is causing requests for the same page to create
16 new JaxpParser components on every invocation, and my posts are an
attempt to move toward finding a solution.
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer 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] Possible bug in SitemapComponentSelector.select() ?
Posted by Vadim Gritsenko <vg...@hns.com>.
Stuart,
</snip>
>
> A request for "new-test_news.html" is going to request
> "cocoon:/select/news/test_news.xml" which, during its processing is going
> to look for JaxpTransformer components from its own pool before that of
> its parent. Consequently, on every call it is going to create a whole new
> pool and set of transformers.
SitemapComponentSelectors (and their pools) are created once during initialization
of (sub)sitemap, and parent is set to appropriate SitemapComponentSelector from the
parent sitemap (or Cocoon itself for main sitemap), see AbstractSitemap.compose() method.
When looking for component, first component from this sitemap is looked up. If none found,
selector attempts to get component from parent.
Are you able to reproduce your problem on Cocoon's example sitemap?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org