Mailing-List: contact jcs-users-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JCS Users List" <jcs-users@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=k45dm/yIwRxf6U+x5V2RWzMfEDLZa8OljRWgAoke44/b5AMHaFrQQgPzU1W5xUniVaNAlgMp2QGQ74me/fxoA638v6qWIrIUOSpXnP1G5tnpTpxooeGi9FLeY6H6npSoI7IVd2g2v/2za93KiVy1C3WLhy74Gtxciu3k6d4Nz0k=
  ;
Message-ID: <20060720193811.3153.qmail@web38714.mail.mud.yahoo.com>
Date: Thu, 20 Jul 2006 12:38:11 -0700 (PDT)
From: Aaron Smuts <asmuts@yahoo.com>
Subject: RE: question regarding removing a cachekey according the correct
 eviction policy from the outside
To: JCS Users List <jcs-users@jakarta.apache.org>
In-Reply-To: <A955EA1F8FE31749AEC8C998082F6C7CD6E739@hai01.hippo.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

We can add a free( int numberToFree ) method to the
memory cache interface.  The expected behavior will be
that that any memory cache should delete the items
that would be next to go given its eviction policy. 
This should do the trick.  The LRUMemoryCache will
just spool the "numberToFree" least recently used
items.

You'll still have to get the memory cache from the
composite cache, since this method is not general
enough for all types of cache auxiliaries.  We could
put it in the JCS convenience class as well, so you
wouldn't have to deal with JCS at such a low level.

Aaron

--- Ard Schrijvers <a.schrijvers@hippo.nl> wrote:

> 
> > 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 <a.schrijvers@hippo.nl> 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
> > >
> >
>
-------------------------------------------------------------
> > > a.schrijvers@hippo.nl / http://www.hippo.nl
> > >
> >
>
--------------------------------------------------------------
> > > 
> > > 
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jcs-users-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jcs-users-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> > 
> > 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org