Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
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.
Yes async will do the trick. And IMHO it should be Ok to alter sync
implementation to keep previous response if new one can't be obtained.
sounds easier than Ard's proposal (no offense ;-) ), or do I overlook
something?
Actually it already should be working this way? See CachingSource line 427.
I guess with some additional configuration it should be possible to get this
stuff working but ...
TBH, I only want to have a url like
caching:http://www.example.org/rss.xml?cocoon:cache-expires=600 without any
further configuration. The content should be available whatever happens to the
RSS feed and should even survive restarts of Cocoon by default. After 10 minutes
it should be tried to update it but shouldn't throw away the previous content in
the case that the refresh runs into an exception.
This brings me to another point: What is the best option for the retry strategy?
There could be some smart default value (e.g. 10 % of the cache-expires value
... don't know whether this is really smart ;-) ) that could be overrided by a
cocoon:cache-retry parameter. WDYT?
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
I do not think it has any dependencies on cron, where do you see it?
either it comes through a transitive dependency or I did something
wrong with my setup. I will check where it comes from.
Let the source be with you, ;-)
There are no deps in the source code.
The dependency is declared at POM level:
repository -> event-cache- -> jms -> cron
But true, the CachingSource itself (probably) only depends on classes in the
event-cache block.
What I wanted to point out was that I need all 4 blocks (+ all libs they depend
on) just to get the CachingSource working ...
just for this. Any comments before I start a vote on this?
Async is a basic functionality which must be in core, IMHO. But I
completely agree that event-cache and jms should be optional. I was
planning on doing this refactoring but did not manage to do it so far.
It would be great if you could help me with the design of the
refactoring: If you did it, into which parts would you split it up?
IIRC, the only dependency on event-aware block was due to usage of
EventValidity (and the questionable instanceof EventAware). So my plan
was to refactor current implementation into two classes, one is base and
second extending the base implementation and providing support for event
aware caching by overriding getCacheValidities() and checkValidity()
(grep for 'event').
thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
