Ard Schrijvers wrote:
1) How it works and its intention (I think :-) ): The StoreJanitor is
originally invented to monitor cocoon's memory useage and does this by
checking some memory values every X (default 10) seconds. Beside the fact
that I doubt users know that it is quite important to
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.
Ard Schrijvers wrote:
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.
Yes because it is stable and works better and at the time I last looked into it
JCS was really not an option
Configurable Store registration with StoreJanitor alleviates
somewhat that
problem, but not solves completely as you still have to
properly configure all
your cache sizes correctly to avoid OOM.
I think you can try combining Cocoon's MRU cache and EHCache
to get best of both
Hello,
Ard Schrijvers wrote:
i would be glad to share the code and my ideas, for example
about this whole
StoreJanitor idea :-) )
Just curious, what did you mean by this whole StoreJanitor idea?
Before I say things that are wrong, please consider that the StoreJanitor was
invented
/snip
?? my mail got sended by accident :Sfinishing it now
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:
store logger=core.store
parameter