You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by James Winburn <jw...@computerguidance.com> on 2008/11/13 22:35:08 UTC
Caching problem
First of all, we would like to thank you for letting us subscribe to the
jetspeed-dev user group.
We are running Jetspeed-2.1.3 with Tomcat and MySQL 5.0. We would like
the portal to be driven by the database in the sense that changes to the
portal ( maintenance of pages, fragments, and user preferences) can only
come about from changes to database tables (i.e. no user has edit access
to any page or portlet.) We have been relatively successful in this.
The only remaining problem is that when the database is updated, it can
take up to ten minutes for the change to propagate to the portal. We
can, of course, bounce Tomcat and the change is propagated right away,
but we would rather not do that.
This would seem to be an issue with a cache timing out somewhere, but we
aren't sure where that cache might be. The <expiration-cache> tag in
portlet.xml appears to be a cache for the portlet output only. Setting
it to a smaller number has no effect on when the portal refreshes itself
from database data.
We're surely missing something and were hoping that you guys might be
able to point us in the right direction.
Thank you,
James Winburn
Computer Guidance Corporation
Scottsdale, AZ
RE: Caching problem
Posted by James Winburn <jw...@computerguidance.com>.
-----Original Message-----
From: David Sean Taylor [mailto:david@bluesunrise.com]
Sent: Thursday, November 13, 2008 3:32 PM
To: Jetspeed Developers List
Subject: Re: Caching problem
On Nov 13, 2008, at 1:35 PM, James Winburn wrote:
> First of all, we would like to thank you for letting us subscribe to
> the
> jetspeed-dev user group.
>
>
>
> We are running Jetspeed-2.1.3 with Tomcat and MySQL 5.0. We would
> like
> the portal to be driven by the database in the sense that changes to
> the
> portal ( maintenance of pages, fragments, and user preferences) can
> only
> come about from changes to database tables (i.e. no user has edit
> access
> to any page or portlet.) We have been relatively successful in this.
> The only remaining problem is that when the database is updated, it
> can
> take up to ten minutes for the change to propagate to the portal. We
> can, of course, bounce Tomcat and the change is propagated right away,
> but we would rather not do that.
>
>
>
> This would seem to be an issue with a cache timing out somewhere,
> but we
> aren't sure where that cache might be. The <expiration-cache> tag in
> portlet.xml appears to be a cache for the portlet output only.
> Setting
> it to a smaller number has no effect on when the portal refreshes
> itself
> from database data.
>
>
>
> We're surely missing something and were hoping that you guys might be
> able to point us in the right direction.
>
It sounds like you are using the Database Page Manager, although its
not entirely clear from what you said above.
The Spring configuration controls the lifetime of the page cache. For
file-based PSML, see page-manager.xml configuration:
<bean id="PageFileCache"
class="org.apache.jetspeed.cache.file.FileCache" init-
method="startFileScanner" destroy-method="stopFileScanner">
<!-- Scan rate for changes in cached files on the file system
-->
<constructor-arg index="0">
<value>10</value>
</constructor-arg>
<!-- Cache size -->
<constructor-arg index="1">
<value>100</value>
</constructor-arg>
</bean>
For Database PSML, see the similiar db-page-manager.xml:
<!-- DB PageManager -->
<bean id="org.apache.jetspeed.page.PageManagerImpl"
name="pageManagerImpl"
init-method="init"
class="org.apache.jetspeed.page.impl.DatabasePageManager">
<!-- OJB configuration file resource path -->
<constructor-arg index="0"><value>JETSPEED-INF/ojb/page-manager-
repository.xml</value></constructor-arg>
<!-- folder/page/link cache size, default=128, min=128 -->
<constructor-arg index="1"><value>128</value></constructor-arg>
<!-- folder/page/link cache expires seconds, default=-1,
infinite=0, min=30 -->
<!-- (default is 150
seconds) -->
<constructor-arg index="2"><value>-1</value></constructor-arg>
<!-- permissions security enabled flag, default=false -->
<constructor-arg index="3"><value>false</value></constructor-arg>
<!-- constraints security enabled flag, default=true -->
<constructor-arg index="4"><value>true</value></constructor-arg>
</bean>
Thank you, David, but modifying the page cache in db-page-manager.xml
(our psml information is in the database) had no effect on the database
cache. It still takes 600 seconds to timeout and re-read the database.
On the chance that you have no further ideas, I will concentrate my
research on seeing what database caches Tomcat or MySQL might have. :)
James Winburn
Computer Guidance Corporation
Scottsdale, AZ
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Caching problem
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Nov 13, 2008, at 1:35 PM, James Winburn wrote:
> First of all, we would like to thank you for letting us subscribe to
> the
> jetspeed-dev user group.
>
>
>
> We are running Jetspeed-2.1.3 with Tomcat and MySQL 5.0. We would
> like
> the portal to be driven by the database in the sense that changes to
> the
> portal ( maintenance of pages, fragments, and user preferences) can
> only
> come about from changes to database tables (i.e. no user has edit
> access
> to any page or portlet.) We have been relatively successful in this.
> The only remaining problem is that when the database is updated, it
> can
> take up to ten minutes for the change to propagate to the portal. We
> can, of course, bounce Tomcat and the change is propagated right away,
> but we would rather not do that.
>
>
>
> This would seem to be an issue with a cache timing out somewhere,
> but we
> aren't sure where that cache might be. The <expiration-cache> tag in
> portlet.xml appears to be a cache for the portlet output only.
> Setting
> it to a smaller number has no effect on when the portal refreshes
> itself
> from database data.
>
>
>
> We're surely missing something and were hoping that you guys might be
> able to point us in the right direction.
>
It sounds like you are using the Database Page Manager, although its
not entirely clear from what you said above.
The Spring configuration controls the lifetime of the page cache. For
file-based PSML, see page-manager.xml configuration:
<bean id="PageFileCache"
class="org.apache.jetspeed.cache.file.FileCache" init-
method="startFileScanner" destroy-method="stopFileScanner">
<!-- Scan rate for changes in cached files on the file system
-->
<constructor-arg index="0">
<value>10</value>
</constructor-arg>
<!-- Cache size -->
<constructor-arg index="1">
<value>100</value>
</constructor-arg>
</bean>
For Database PSML, see the similiar db-page-manager.xml:
<!-- DB PageManager -->
<bean id="org.apache.jetspeed.page.PageManagerImpl"
name="pageManagerImpl"
init-method="init"
class="org.apache.jetspeed.page.impl.DatabasePageManager">
<!-- OJB configuration file resource path -->
<constructor-arg index="0"><value>JETSPEED-INF/ojb/page-manager-
repository.xml</value></constructor-arg>
<!-- folder/page/link cache size, default=128, min=128 -->
<constructor-arg index="1"><value>128</value></constructor-arg>
<!-- folder/page/link cache expires seconds, default=-1,
infinite=0, min=30 -->
<!-- (default is 150
seconds) -->
<constructor-arg index="2"><value>-1</value></constructor-arg>
<!-- permissions security enabled flag, default=false -->
<constructor-arg index="3"><value>false</value></constructor-arg>
<!-- constraints security enabled flag, default=true -->
<constructor-arg index="4"><value>true</value></constructor-arg>
</bean>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org