> JCS is completely pluggable, unlike eh*%$^. Hence,
> you can provide your own memory cache. An easy way to
> do this would be to extend the LRUMemoryCache and
> provide the logic that you need.
>
> Since JCS is jdk1.3 compliant, I have not created any
> memory size related methods. I will eventually put in
> a memory cache that will balk if some percentage of
> total memory is consumed. Alternatively, you could
> spool the last item whenever some configurable
> percentage of memory has ben reached.
That does not matter for us, because in cocoon, the StoreJanitor takes care of
actual memory consumed, and acts when necessary. All it does, is estimate the
number of keys to be removed (memoryStoreKeys, not diskStoreKeys), and remove
these. So, in a loop for example the free() method of the JCSDefaultStore is
called. But this free() method removes keys starting from index 0. Do you think
that extending the LRUMemoryCache would give me the possibility to remove keys
according the correct eviction policy?
>
> Also, I'm working on a configuration option that will
> allow you to put all items to disk and not just those
> that are spooled.
You mean I can manually spool a number X cached responses to disk according the
correct eviction policy without being at maxObjects in memoryStore?
Regards Ard
>
> Aaron
>
>
>
> --- Ard Schrijvers <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > I have a question regarding removing keys:
> >
> > In cocoon we have a JCSDefaultStore implementing
> > org.apache.excalibur.store.Store interface. This
> > interface has a method free(). store.free() (store
> > can be the EHDefaultStore (ehcache) or the
> > JCSDefaultStore, etc etc) is invoked by
> > org.apache.excalibur.store.impl.StoreJanitorImpl
> > when the JVM is low on memory.
> >
> > Free() tries to remove cachekeys+response to free
> > some memory. For example, the JCSDefaultStore does
> > it like below:
> >
> > public void free() {
> > // TODO Find a better way
> > MemoryCache memoryCache =
> > this.cacheManager.getCache(region).getMemoryCache();
> > Object[] keys = memoryCache.getKeyArray();
> > if ( keys != null && keys.length > 0 ) {
> > final Object key = keys[0];
> > try {
> >
> > memoryCache.remove((Serializable)key);
> > } catch (Exception ignore) {
> >
> > }
> > }
> > }
> >
> > The TODO speaks for itself. The EHDefaultStore using
> > ehcache has this very same problem. Just removing
> > cachekeys starting at index 0 does not improve the
> > JVM when requests keep coming in, and the mainly
> > important keys have been removed.
> >
> > I was told that from the outside, it is impossible
> > to remove keys from the ehcache according the
> > correct eviction policy. Does this also hold for
> > JCS? And, furthermore, perhaps I just want to
> > overflow the cached responses to disk (without
> > having reached maxobjects) instead of removing them.
> > That would clear memory and let me keep the cached
> > responses.
> >
> > Is there something possible like,
> >
> > public void remove(int numberKeys) and
> > public void overflow(int numberKeys)
> >
> > and that this is done according the correct eviction
> > policy?
> >
> > Regards Ard
> >
> > --
> >
> > Hippo
> > Oosteinde 11
> > 1017WT Amsterdam
> > The Netherlands
> > Tel +31 (0)20 5224466
> >
> -------------------------------------------------------------
> > [EMAIL PROTECTED] / http://www.hippo.nl
> >
> --------------------------------------------------------------
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
