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. 


> 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 
valid
 * 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. 

Ard

[1] http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g7/g1/675.html

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

Reply via email to