forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Date Mon, 28 Jul 2008 09:14:07 GMT
On Sat, 2008-07-26 at 19:04 -0700, Brian M Dube wrote:
> Thorsten Scherler wrote:
> > On Sun, 2008-07-20 at 22:51 -0700, Brian M Dube (JIRA) wrote:
> >> [ https://issues.apache.org/jira/browse/FOR-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615152#action_12615152
] 
> >>
> >> Brian M Dube commented on FOR-803:
> >> ----------------------------------
> >>
> >> I'm developing a plugin that uses Hibernate ORM capabilities, and I have Hibernate
configured to display its SQL statements as it hits the database while I test. With the pelt
skin, the database is hit a few times and the page finishes rendering. 
> > 
> > Actually I reckon it should be one match not more. What are the matches?
> 
> What matches are you talking about? I'm talking about SQL statements, 
> and in this case it takes more than one SQL statement to retrieve the 
> data for the page.

I am talking about matches in cocoon. I imaging that the plugin will
expose the data from the db via sitemap matches. This matches should be
cacheable that cocoon will answer multiple request to the same match.

In dispatcher we call this dataModel or connector since it producing the
raw xml data which will then be used in the contracts.

> 
> >> With the pelt theme, the database is hit over and over again for the same information
before rendering the page. 
> > 
> > That indicates a bug in the data-source plugins (if catching is enabled
> > the cache should return the hit and not pass it through the db plugin).
> 
> 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" />.

Now since the idea is that the structurer is the configuration for the
dispatcher (as front end controller) each contract you use can be
injected with your dataUri and the resulting xml will be transformed
with the contracts xsl. 

If you see lots of request to one and the same data source then this
datasource should be chached.

> 
> >> 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).

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message