Hi Hardy,
I've used the "clearcache" functionality on our production site, and it is
useful for performing manually, when your site is just stuck. I think it
would be best to hide the url in a location that public users can't access
<site>/protected/clearcache, just because they shouldn't have access to
that.
I think that some of our admins know that they can visit the clear-cache
page after they create a new top-level-community to get it to appear in the
community-list.
<map:action name="ClearCache"
src="org.apache.cocoon.acting.ClearCacheAction" />
I haven't toyed with the idea of running a cron clear-cache, because our
problem isn't that bad.
Peter Dietz
On Thu, Oct 13, 2011 at 5:35 PM, Pottinger, Hardy J. <
[email protected]> wrote:
> Hi, a recent thread on dspace_tech [1] got me thinking about my previous
> experiences with caching, in other web development environments. In
> particular, a few years back, I did a lot of development using a PHP-based
> framework called ezPublish, and it had a caching scheme that could, on
> occasion, become aggressive. Their recommended safety net was to run a
> cron job to clear the cache every hour or so. Yeah, I know, kinda crazy
> (it's obviously a good way to hide a more serious bug). But part of me
> wants to code something similar (a command-line script for clearing the
> XMLUI/Cocoon cache), just to slap a bandaid on the problem and keep moving.
>
> I mentioned this idea to Tim Donohue and Mark Diggory, to get their
> thoughts on whether I should chase after this impulse, and Mark suggested
> an alternative that would utilize the same idea (expiring the Cocoon
> cache) using existing functionality of Cocoon (my apologies to Mark for
> the cut and paste quoting to tell the story):
>
> On 10/13/11 11:53 AM, "Mark Diggory"<[email protected]> wrote:
> >We can actually utilize an expires parameter in the cocoon pipeline which
> >would force all caching to reload on a specified time period. TBH, I
> >would prefer this over the current situation, the real benefit of caching
> >is when there are multiple requests all piled on top of each other. So
> >yea Hardy, I agree with the premis of what your suggesting.
>
>
> On 10/13/11 2:55 PM, "Mark Diggory" <[email protected]> wrote:
> >Here is the detail for the 2.2 based approach which has a bit more
> >configurability.
> >http://cocoon.apache.org/2.2/core-modules/core/2.2/939_1_1.html
> >Note that we can get away with this by replacing one line in the default
> >sitemap :-) (look at other sitemaps to verify if its been overriden as
> >well).
> >
> ><map:pipe name="caching"
> >
> >src="org.apache.cocoon.components.pipeline.impl.ExpiresCachingProcessingPi
> >peline">
> > <parameter name="cache-expires" value="180"/> <!-- Expires in seconds
> >-->
> ></map:pipe>
>
>
> Tim suggested that I send a note to dspace_developers to run this idea
> past a few of you. I think Mark has a good handle on what needs to change,
> and I think this should be a very simple change to implement. Hopefully in
> time for 1.8? I know it's very last-minute, but it's a simple change to
> the pipeline.
>
>
> I do intend to write a command line cache-clearing script at some point in
> the future, as an additional safety net. My experience with caching
> systems is that, even with expiry, they do tend to clog up. But, I believe
> that utilizing the expiration feature of the Cocoon caching pipeline is a
> good first step.
>
> Thoughts?
>
> [1] http://dspace.2283337.n4.nabble.com/item-counter-failed-td3896963.html
>
> --
> HARDY POTTINGER <[email protected]>
> University of Missouri Library Systems
> http://lso.umsystem.edu/~pottingerhj/
> https://MOspace.umsystem.edu/
> "Debug only code. Comments lie."
>
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
