://github.com/ggruber4711/cocoon/tree/COCOON-2369_UpgradeRhino)
> StoreJanitor cannot work with more than ~2 gb memory
>
>
> Key: COCOON-2291
> URL: https://issues.apache.org/jira/browse/COCOON-2291
>
does the work:
https://github.com/ggruber4711/cocoon/tree/COCOON-2369_UpgradeRhino
> StoreJanitor cannot work with more than ~2 gb memory
>
>
> Key: COCOON-2291
> URL: https://issues.apache.org/jira
Provide configuration option for StoreJanitor to invoke flush and clear instead
of free on stores that allow for disk overflow (e.g. EHDefaultStore
StoreJanitor cannot work with more than ~2 gb memory
Key: COCOON-2291
URL: https://issues.apache.org/jira/browse/COCOON-2291
Project: Cocoon
Issue Type: Bug
Components: * Cocoon
it briefly and works fine. Closing the issue.
> StatusGenerator must now show default Store explicitly (because no longer
> part of StoreJanitor)
> ---
>
> K
ore explicitly (because no longer
> part of StoreJanitor)
> ---
>
> Key: COCOON-2054
> URL: https://issues.apache.org/jira/browse/COCOON-2054
>
StatusGenerator to explicitly show the data for Store.ROLE, same
as showing it for Store.PERSISTENT_STORE, both sharing the same method.
> StatusGenerator must now show default Store explicitly (because no longer
> part of StoreJ
StatusGenerator must now show default Store explicitly (because no longer part
of StoreJanitor)
---
Key: COCOON-2054
URL: https://issues.apache.org/jira/browse/COCOON
Ard Schrijvers wrote:
Strictly speaking, you don't need access to the eviction
policy itself - but
only some exposed method on Store, something like
purgeLastElementAccordingToEvictionPolicy -- can't they add
something like that?
I of course did ask this, because this is obviously the way t
>
> 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
(it was working with O(n) complexity at the time),
and EHCache was not completely implemented (as it still the case).
Configurable Store registration with StoreJanitor alleviates somewhat that
problem, but not solves completely as you still have to properly configure all
your cache sizes
like maxelements (memory) and maxdiskelements
should be modifable during run time, but, this is not possible with ehcache
or jcs.
No real objection here. But you would not need this if StoreJanitor functions
correctly.
Granted it can't be implemented cleanly in Java 1.4 (hence thread +
int
>
> Strictly speaking, you don't need access to the eviction
> policy itself - but
> only some exposed method on Store, something like
> purgeLastElementAccordingToEvictionPolicy -- can't they add
> something like that?
I of course did ask this, because this is obviously the way to go:
ht
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:
Ard Schrijvers wrote:
Yes, this is exactly my point. The extra problem is that
the StoreJanitor
never has access to the eviction policy of the cache, and
just starts
throwing out entries "at random".
That's incorrect statement. I'd say that Sto
for different jvm mem values). Throwing away all cache experience of
others
and switch to cocoon cache does't seem to make sense to me
>
>
> > JCS will probably do the same. I guess that original purpose of
> > StoreJanitor was when Cocoon had its own store implemen
> Ard Schrijvers wrote:
> > Yes, this is exactly my point. The extra problem is that
> the StoreJanitor
> > never has access to the eviction policy of the cache, and
> just starts
> > throwing out entries "at random".
>
> That's incorrect st
Ard Schrijvers wrote:
Yes, this is exactly my point. The extra problem is that the StoreJanitor
never has access to the eviction policy of the cache, and just starts
throwing out entries "at random".
That's incorrect statement. I'd say that StoreJanitor always has acc
Reinhard Poetz wrote:
I wonder what StoreJanitor is good for at all. EHCache takes care that
the number of items in the memory cache doesn't grow indefinitly and
starts its own cleanup threads for the disc store
(http://ehcache.sourceforge.net/documentation/storage_options.html#Disk
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 importa
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
> >
> > I'm interested in fu
rent configurations?
> > > I can try to write extended documentation on what IMO is
> best for configuration, and "tricks" to
> > > avoid the StoreJanitor mechanism
> >
> > I'm interested in further comments by you too, but actually
> I meant that o
tation on what IMO is best for configuration, and
"tricks" to
> avoid the StoreJanitor mechanism
I'm interested in further comments by you too, but actually I meant that other
people should comment on our plan to change the behaviour of StoreJanitor.
Personally, I wonder if
avoid the StoreJanitor mechanism
I'm interested in further comments by you too, but actually I meant that other
people should comment on our plan to change the behaviour of StoreJanitor.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Sourc
>
> 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
> regi
Ard Schrijvers wrote:
- introduce a maxPersistentObjects parameter and use it in
EHDefaultCache to set maxElementsOnDisk
+1
that's easy
- make the registration of stores at StoreJanitor configureable
(Though I wonder what the default value should be, true or false?)
behind (like when putting
a timestamp in a cachekey).
>
> I wonder what StoreJanitor is good for at all. EHCache takes
> care that the
> number of items in the memory cache doesn't grow indefinitly
> and starts its own
> cleanup threads for the disc store
> (http://ehcache
>
> Reinhard Poetz wrote:
>
> > P.S. Ard, answering to your mails is very difficult because
> there are no
I am very sorry...I hardly dare saying i am using outlook :-)
I'll try to find a way in the stupid program for linebreaks or make the switch
to Thunderbird.
Ard
> > line breaks.
Reinhard Poetz wrote:
P.S. Ard, answering to your mails is very difficult because there are no
line breaks. Is anybody else experiencing the same problem or is it only
me?
Jörg pointed me to the "rewrap" function of Thunderbird. Using it fixes all my
problems with never ending lines. Thanks
Ard Schrijvers wrote:
> Before I say things that are wrong, please consider that the StoreJanitor was
invented long before I looked into the cocoon code, so probably a lot of
discussion and good ideas has been around which I am not aware of. But still, my
ideas about the StoreJanitor (
?? 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:
where size might be small, medium,
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
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"?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Eng
Carsten Ziegeler wrote:
The docs for the store janitor recommend to set the max heap size
to -Xmx. With JDK 1.4.1 and -Xmx set to 192mb, this is 201326592.
However, the total memory of the jvm as reported by the store janitor
is 199819264 which is less than the value above.
Now, the store janitor
The docs for the store janitor recommend to set the max heap size
to -Xmx. With JDK 1.4.1 and -Xmx set to 192mb, this is 201326592.
However, the total memory of the jvm as reported by the store janitor
is 199819264 which is less than the value above.
Now, the store janitor checks during the memory
vgritsenko2003/07/30 20:45:24
Removed: src/scratchpad/src/org/apache/cocoon/storejanitor
StoreJanitorImpl.java
Log:
Adaptive interval calculation is now in excalibur
vgritsenko2003/07/30 20:43:24
Removed: src/scratchpad/src/org/apache/cocoon/storejanitor
StoreJanitorImpl.java
Log:
Adaptive interval calculation is now in excalibur
37 matches
Mail list logo
