cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Moving reduced version of CachingSource to core | Configuration issues
Date Mon, 26 Mar 2007 17:31:18 GMT
Reinhard Poetz wrote:
> 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.

I think I know what you mean. It clears cache if not-async, at line 196. But it 
should be relatively easy to modify it to use previously cached response if new 
response isn't available.

As for restarts, it should survive them if Cache is persisted, right?


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

There are two simplest strategies I see - use same expires value for retry 
interval, and use 0 for retry interval - so it would either just skip this 
reload or try reload on each subsequent request.

And there are a myriad of smarter strategies, so pick any you'd like...


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

I have it working only with repository and eventcache jars. After you refactor & 
move caching source to core, eventcache won't be required anymore.

Vadim

Mime
View raw message