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
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?)
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}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
