cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Moving reduced version of CachingSource to core | Configuration issues
Date Mon, 26 Mar 2007 14:27:21 GMT
Ard Schrijvers wrote:
> Hello Reinhard,
>> The repository block contains a the CachingSource. Does 
>> anybody have experiences 
>> with it?
> Yes, we do have a lot of experience with it (though we have a slightly different version
(Max Pfingsthorn changed it: the public SourceValidity getValidity() returns an eventValidity
in our version instead of a timeStampValidity, but this is not according CacheableProcessingComponent
Contracts [1] and it gave me *many* headaches to fix it all because many components use implicit
caching which depend on source validity and as we all know, an eventValidity returns valid
by defenition, so these cachings never get flushed. If I knew all this before, I would have
reverted the change long ago :-(  )  
>> I wonder how I can configure it so that the cached source 
>> expires e.g. after 5 
>> minutes but if it can't be updated (e.g. the wrapped source 
>> isn't available), 
>> the expired version should be used.
> You probably know how to configure default-expires configuration and expires per generator,
right? But this is probably not what you mean:
> in configure:
> this.defaultExpires = parameters.getParameterAsInteger(DEFAULT_EXPIRES_PARAM, -1);
> and 
> int expires = params.getParameterAsInteger(CachingSource.CACHE_EXPIRES_PARAM, this.defaultExpires);
> in getSource(...) , but you probably already knew this
> I do not really understand your feature? First, you have generated a repository source.
Then, if it is expired, you want to refetch the source, but is if it isn't there, use the
expired cached object? IMO, it is a strange thing to do (apart from how to integrate it in
the current cache impl, that checks for validities of the cached response. but...i must be
missing your point I think?). I have been thinking though for something like this to enable
fetching remote rss feeds for example, that when the connection to this rss feed is lost (the
remote site is down), your application still runs (or is this actually your use case? ). In
that case, I would suggest a different mechanism, because the one you describe does not really
fit in the cachingsource IMO. 

yes, the "broken connection" scenario is that what I want. If you say that it 
doesn't really fit into the caching source, what do you propose instead? Writing 
another source wrapping source for this purpose only? (Could be easier than to 
refactor the existing one ...)

>> I would like to add this 
>> feature in a 
>> transparent way and provide a configuration parameter to 
>> switch it off if you 
>> _don't_ want this behaviour but I'm not sure if I duplicate 
>> something that 
>> already exists.
>> I can think of setting the expires parameter to -1 and using a 
>> background-refresher but this seems to be overly complex for 
>> this simple task.
> The documentation says:
>  * <p>The value of the expires parameter holds some additional semantics.
>  * Specifying <code>-1</code> will yield the cached response to be considered
>  * always. Value <code>0</code> can be used to achieve the exact opposite.
That is to say,
>  * the cached contents will be thrown out and updated immediately and unconditionally.<p>
> You want to change the -1 expires behavior, into something that after the expires of
eg 5 minutes you have a background fetch (and have this in a cron job or something?) 

no, no, I don't want to change the behaviour of -1. I tried to explain that I 
*could* use it together with a background fetcher to reach my goal but this is 
overly complex for such a simple thing.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message