cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: Moving reduced version of CachingSource to core | Configuration issues
Date Mon, 26 Mar 2007 14:13:23 GMT
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);


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. 

> 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?) 

> I would also like to move the basic functionality of the 
> CachingSource into some 
> core module and only have an extended versions (event-cache 
> support, async 
> updating) of it in the reposistory block. I seems odd to me 
> that I have to add a 
> dependency to the repository block, the event-cache block, 
> the jms block and the 
> cron block just for this. Any comments before I start a vote on this?

You indeed have to add quite some jars to enable the cachingsource. The cron job is needed
for jms reconnection only, the eventcache and jms are unseperatable. But, IMO, there shouldn't
have to be a direct relation between the cachingsource, which is just some sort of proxy,
and the eventcache, jms and cron block. Wanting to use the cachingsource without the eventblock
seems a legitimate goal IMO. 



> -- 
> Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>                                         web(log):
> --------------------------------------------------------------------

View raw message