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
Date Wed, 04 Apr 2007 10:18:47 GMT

> 
> I suggest that we don't register them at StoreJanitor by 
> default anymore but 
> make it configureable for users who rely on it in their custom Store 
> implementations/configurations.

+1

> 
> AFAIU, StoreJanitor only runs if at least one store is 
> registered so we don't 
> have to remove it.
> 
> >>   - fix EventRegistry
> > 

</snip>

> 
> I have to learn more about the EventRegistry in order to 
> comment on your 
> suggestions.

I will mail tonight or tomorrow morning all ins and outs, pros and cons (I know of at least)
of the current
eventRegistry and my suggested (implemented) fix (though we have to discuss wether I can get
it to work for EHCache and wether it needs to be diskpersistent between JVM restarts)

> 
> > 4) you have a memory leak in some custom component (a 
> little vague yes :-) )
> > ....etc
> 
> hehe, if we can implement an algorithm that can provide such 
> analysis reliably, 
> why not ;-)

I think this is extremely hard. Not for the pipeline caches because they store the response
in byte[], but for continuations, internal component maps (for example i18n resource bundles
I think, compiled jx), memory stores which contain any complex non serializable objects, I
think it is impossible to know the amount of memory. I test these things the most dumb possible
way you can imagine: I crawl my site, and look in status page what happens. I have
many stores in my status page. I have a clear link for each seperate store, and I look at
the memory which gets
freed when clearing one store. This gives me a heuristic measurement of how large my stores
are and should be configured

> 
> Are you suggesting some kind of online monitor? I think 
> having a seperate 
> component would be better than merging it into StoreJanitor. 
> This component 
> could also be made available as MBean.

See above, very complex I think...and if we fix the standard things that it is harder for
users to 
get bugged by the StoreJanitor, and they want to take it to the next level, there are always
things
like yourkit profiler. But, perhaps I am not ambitious enough now :-) 
> 

> 
> yes please, I would be interested in more comments too! Are 

more comments like in wiki or in the cocoon.xconf more comment for different configurations?

I can try to write extended documentation on what IMO is best for configuration, and "tricks"
to 
avoid the StoreJanitor mechanism

> Ard and I right that 
> we shouldn't register EHDefaultStore and MRUMemoryStore at 
> StoreJanitor anymore 
> by default and make it configureable instead?

In principle, you could see the StoreJanitor as a real last resort (but IMO, it will never
actually help). 
The StoreJanitor might still run, and give proper warnings when low on memory. Configuring
your stores correctly
(and making sure no binary files of many Mb's end up in it), and certainly having the maxdiskelements

configured should do the trick! Not running the StoreJanitor when JVM is low, will result
in a little faster OOM,
but in my opinion, it differs not much. I also think, the maxdiskelements should have a sensible
default, which
should be less then indefinitely (something like 30.000-50.000 should cover I think almost
everybodies apps)

> 
> > Ard
> > 

> 
> the formatting is okay now, but it seems that your mails 
> still don't set the 
> in-reply-to header correctly.

Hmmm, I will start using Thunderbird on short notice (not yet today :-) )

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