You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Brian M Dube (JIRA)" <ji...@apache.org> on 2008/07/21 07:51:31 UTC
[jira] Commented: (FOR-803) Profile new dispatcher plugins
[ 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. With the pelt theme, the database is hit over and over again for the same information before rendering the page. 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.
> Profile new dispatcher plugins
> ------------------------------
>
> Key: FOR-803
> URL: https://issues.apache.org/jira/browse/FOR-803
> Project: Forrest
> Issue Type: Sub-task
> Components: Plugin: internal.dispatcher
> Reporter: Thorsten Scherler
>
> http://marc.theaimsgroup.com/?t=113830245600001
> El sáb, 28-01-2006 a las 23:10 +1100, David Crossley escribió:
> A while ago i noticed big performance problems.
> > e.g. building site-author took four times as long.
> >
> > We need to do at least basic profiling.
> http://marc.theaimsgroup.com/?l=forrest-dev&m=113845026822103&w=2
> David was talking about v2 but this needs to be verified with the refactored version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Posted by Brian M Dube <bd...@apache.org>.
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.
>> 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?
>> 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.
Brian
Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Posted by 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
Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
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
Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Posted by Brian M Dube <br...@gmail.com>.
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.
>> 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?
>> 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.
Brian
Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Posted by Thorsten Scherler <th...@apache.org>.
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?
> 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).
> 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.
TIA
salu2
>
> > Profile new dispatcher plugins
> > ------------------------------
> >
> > Key: FOR-803
> > URL: https://issues.apache.org/jira/browse/FOR-803
> > Project: Forrest
> > Issue Type: Sub-task
> > Components: Plugin: internal.dispatcher
> > Reporter: Thorsten Scherler
> >
> > http://marc.theaimsgroup.com/?t=113830245600001
> > El sáb, 28-01-2006 a las 23:10 +1100, David Crossley escribió:
> > A while ago i noticed big performance problems.
> > > e.g. building site-author took four times as long.
> > >
> > > We need to do at least basic profiling.
> > http://marc.theaimsgroup.com/?l=forrest-dev&m=113845026822103&w=2
> > David was talking about v2 but this needs to be verified with the refactored version.
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions