cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Moving reduced version of CachingSource to core | Configuration issues
Date Mon, 26 Mar 2007 15:18:32 GMT

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

It does fit in the current caching source without touching the caching source I think :-)


> Writing 
> another source wrapping source for this purpose only? (Could 
> be easier than to 
> refactor the existing one ...)

IMO, it is quite simple to implement this in the current code, without touching anything.
I think step-by-step this needs to be done, and I can help if you want

1) you define a new source-factory in cocoon.xconf:

<component-instance class="org.apache.cocoon.components.source.impl.CachingSourceFactory"
logger="core.source.caching" name="cached">
        <parameter name="cache-role" value="org.apache.cocoon.caching.Cache/ExpiresAware"/>
      </component-instance>

if you want to prefix you source-factory for the expires cron gets different change "cached"
into "expires-aware" or something

2) A new class, ExpiresAwareCacheImpl with role

<role default-class="org.apache.cocoon.caching.impl.ExpiresAwareCacheImpl" name="org.apache.cocoon.caching.Cache/ExpiresAware"
shorthand="expires-aware"/>

3) <expires-aware logger="core.cache.expires">
      <parameter name="store" value="org.apache.excalibur.store.Store"/>
      <parameter name="expiresregistry" value="org.apache.cocoon.caching.ExpiresRegistry"/>
  </expires-aware>

Now, like the EvantAwareCacheImpl, your ExpiresAwareCacheImpl examines a cachedresponse before
actually storing it in the cache, and checks for expires validities. If found, store this
like the eventRegistry in a registry, based on  some multi value maps: [expiresvalue,{key1,key2,key3}]
(by the way, you have to store the uri of the source also ofcourse)

Now, there runs a cron job, checking this ExpiresRegistry, and if expired values found, do
a refetch: if refetch succesfull: clear the cached entry and store new cached response and
register new expires time. 

OTH, relying havely on this mechanism might result it naste registry behavior resulting in
OOM. Therefor, I changed the event registry we use and use WeakReferencesRegistry instead
of the AbstractDoubleMapEventRegistry, but this for obscure reasons did not work with EHCache
which did not seem to honor my WeakReferences of cachekeys when overflowing cached objects
to disk (I have tried to reproduce without cocoon, but did not succeed), and therefor, I moved
to JCSCache, which does work quite a bit better IMO, though it has an insane complex configuration
(at least, I found it complex :-) )....but, all this is only when you have high traffic sites
in combination with *many* event validities like we have, because of the changed cachingsource
impl, returning an eventValidity instead of timestampvalidity (though, if you have OOM bothering
you with eventcache, let me know....or if somebody is interested in the whole story, let me
know. I haven't discussed it yet on this list, because I do not have the idea others have
this problem as serious as I have had (sites having OOM every 2 days because of the eventRegistry)
and  because it would imply not using the EHCache, and some more minor changes..but again,
if somebody is interested, i would be glad to share the code and my ideas, for example about
this whole StoreJanitor idea :-)  )

Anyway, Reinhard, I hope you where able to follow how I would attack the problem, and if I
can help, let me know. We might want to discuss the "registry" OOM problems in this context
as well, because with the ExpiresRegistry analogues to the EventRegistry in combination of
a cache which is configured to have a time2live and time2idle of not eternal, you might run
into similar problems

Regards Ard

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

Mime
View raw message