Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins

[Brian M Dube <bd...@apache.org>]

Thorsten Scherler wrote:
> On Sat, 2008-07-26 at 19:04 -0700, Brian M Dube wrote:
>> Where is dispatcher caching controlled?
> 
> The dispatcher has multiple tier of caching due to the architecture. 
> 
> The main pipeline has first the jx pages (see e.g. common.fv):
> jx:cache-key="#{$cocoon/parameters/getRequest}"
> jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}"
> 
> Then the dispatcher transformer as well is cacheable via the "normal"
> cocoon mechanism (getKey() & getValidity()). You can deactivate the
> caching of the transformer by changing <property
> name="dispatcher.caching" value="on" />.

Ok, it seems that I need to reconfigure to make use of the cache. I've 
changed my plugin's generators to implement 
CacheableProcessingComponent, but I see in the logs that the cache is 
not being used. The cache is checking for the existence of a file based 
on the sitemap match, but there is no file there because the match is 
only a placeholder for data coming from the database. I'm afraid it's my 
lack of Cocoon knowledge that's hurting me here.

>>>> Navigating to another page will eventually use up all of the heap space and the JVM will hang. I increased the amount of memory available to the JVM, and the connection pool ran out of connections.
>>> Can you please fill a stacktrace to which parts are requested twice, we
>>> need to find out where the caching is failing.
>> I've added it to the issue now.
> 
> Hmm, lots of sql but we need to see as well the requested url and the
> sitemap matches provoking the statements (best as well the structurer
> you use).

I'd like to put the plugin in the whiteboard, but it has some 
dependencies that we can't distribute. Perhaps it should be hosted 
elsewhere, like the SourceForge project that Ross has set up for plugins.

Thanks for the help, Thorsten.

Brian