IMO I think that while I originally proposed this solution, it may not
completely undo our current problems. the following changes introduced a
behavior into the XMLUI that no longer allows the page to state it has
changed because the following selector preempts this process and forces
response headers to be set only on the Item last modified state, long before
the caches can be properly evaluated to determine if the full page needs to
be reprocessed or not.
https://jira.duraspace.org/browse/DS-285
it is too too easy to break Cocoon Caching and end up with incorrect
behavior in your site, I do support clearing the cached pipelines with an
expires header as a defensive means to deal with aspects that may not
properly handle invalidating their caches. As was found in the RelatedItems
and RecentlySubmitted Transformers in Discovery. The expires header is more
proactive than having a manual decaching as it allows the application to
stagger the expiration of caches rather than decaching and rebuilding the
caches all at once.
IMO, a periodic expiration of caches should perform sufficiently close to
the same level as never decaching because the reduction in reprocessing
requests that are very close together is where caching excels. Holding the
cache between such calls just ties up resources and increases the overal
footprint of the application
Mark
On Thu, Oct 13, 2011 at 4:04 PM, Peter Dietz <pdiet...@gmail.com> wrote:
> 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. <
> pottinge...@umsystem.edu> 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"<mdigg...@atmire.com> 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" <mdigg...@atmire.com> 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 <pottinge...@umsystem.edu>
>> 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
>> Dspace-devel@lists.sourceforge.net
>> 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
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
--
[image: @mire Inc.]
*Mark Diggory*
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
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
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
