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: StoreJanitor (was: Re: Moving reduced version of CachingSource to core | Configuration issues)
Date Thu, 05 Apr 2007 13:24:31 GMT
Vadim,

I think you are reasoning from a POV of the cocoon cache, but I think you are 
in the minority compared to the number of users which are using EHCache. 
I tried to explain the inevitable OOM of the StoreJanitor in combination of EHCache and
the event registry in a high volume site. 

> 
> 
> > --------o0o--------
> > 
> > The rules I try to follow to avoid the Store Janitor to run
> > 
> > 1) use readers in noncaching pipelines and use expires on 
> them to avoid
> > cache/memory polution
> 
> Better - there is Apache HTTPD for it.

I know, we use both

> 
> 
> > 2) use a different store for repository binary sources
> > which has only a disk store part and no memory part 
> (cached-binary: protocol
> > added)
> 
> Doesn't it result in some frequently used binary resource 
> always read from the disk?

not because as you said, if you also use Apache HTTPD for binary files *and* a reader with
expires. 
I would be surprised to have a 1.000 concurrent users hitting ctrl-f5 at a large binary at
the same time :-) 

> 
> 
> > 3) use a different store for repository sources then for pipeline
> > cache
> 
> Hm, what are the benefits?

because my repository sources are expensive compared to pipeline cache entries. If 
people do not construct proper pipelines, the pipeline cache entries can flood the cache.

By using a different store for my repository sources, I make sure, wrong constructed pipelines
do not harm me by evicting expensive repository sources. 

Do realize that I am talking about high volume sites with many visitors and editor running
live.

Ard

> 
> 
> Vadim
> 
> > 4) replaced the abstract double mapping event registry to use
> > weakreferences and let the JVM clean up my event registry
> > 5)  (4) gave me
> > undesired behavior by removing weakrefs in combination with 
> ehcache when
> > overflowing items to disk (i could not reproduce this, but 
> seems that my
> > references to cachekeys got lost). Testing with JCSCache 
> solved this problem,
> > gave me faster response times and gave me for free to limit 
> the number of
> > disk cache entries. Disadvantage of the weakreferences, is 
> that I disabled
> > persitstent caches for jvm restarts, but, I never wanted 
> this anyway (but
> > this might be implemented quite easily, but might take long 
> start up times) 
> > 6) JCSCache has a complex configuration IMO. Therefor, I 
> added default
> > configurations to choose from, for example:
> > 
> > 
> > 
> > 
> > [1] http://www.minfin.nl [2] http://www.minbuza.nl
> 
> 

Mime
View raw message