jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: question on isSpool=true
Date Tue, 12 Jan 2010 19:43:17 GMT
The indexed disk cache stores the index in memory.  A disk miss requires no IO.

Aaron

--- On Tue, 1/12/10, GAMERMV@nationwide.com <GAMERMV@nationwide.com> wrote:

> From: GAMERMV@nationwide.com <GAMERMV@nationwide.com>
> Subject: Re: question on isSpool=true
> To: "JCS Users List" <jcs-users@jakarta.apache.org>
> Date: Tuesday, January 12, 2010, 10:47 AM
> Thank you!
> 
> Does checking disk cache for presence of an element involve
> a disk I/O? Or the disk cache map (index) remains in memory
> at all times?
> 
> Thank you
> Val
> 
> 
> ----- Original Message -----
> From: Aaron Smuts [asmuts@yahoo.com]
> Sent: 01/12/2010 10:05 AM PST
> To: JCS Users List <jcs-users@jakarta.apache.org>
> Subject: Re: question on isSpool=true
> 
> 
> 
> JCS will look for items in the various auxiliaries in
> configuration order.  If you specify a remote cache in
> the list before a disk cache, then JCS will look in the
> remote cache before the disk cache.  Before JCS looks
> in disk, lateral, or remote auxiliaries, it will first check
> the memory cache.
> 
> So, in your case, if the item is not in memory JCS will
> look on disk.  If it find the item it will retrieve it,
> put it to the memory cache (if the diskUsagePattern is not
> UPDATE and the memory size is not 0).  After the put
> call, the item will be returned to the client.  The put
> functions as any other.  If the memory store is full,
> the least recently used item in memory (assuming that you
> are using the LRU memory cache) will be spooled to
> disk.  Items are queued and asynchronously put to all
> auxiliaries.  So, no you don't have to wait for the
> next item to be written to disk.  You only have to wait
> for it to be queue.
> 
> Aaron
> 
> --- On Tue, 1/12/10, GAMERMV@nationwide.com
> <GAMERMV@nationwide.com>
> wrote:
> 
> > From: GAMERMV@nationwide.com
> <GAMERMV@nationwide.com>
> > Subject: Re: question on isSpool=true
> > To: "JCS Users List" <jcs-users@jakarta.apache.org>
> > Date: Tuesday, January 12, 2010, 9:19 AM
> > thank you.
> >
> > What about part 3 of the question? About disk writing
> being
> > synchronous/blocking.
> >
> > Thanks
> > Val
> >
> >
> > ----- Original Message -----
> > From: Aaron Smuts [asmuts@yahoo.com]
> > Sent: 01/11/2010 07:01 PM PST
> > To: JCS Users List <jcs-users@jakarta.apache.org>
> > Subject: Re: question on isSpool=true
> >
> >
> >
> > The IsSpool, IsLateral, and IsRemote specify whether
> an
> > item will be allowed to go to a disk, lateral, or
> remote
> > auxiliary respectively.  If there is no disk
> auxiliary
> > configured, for instance, the IsSpool value is
> > irrelevant.  By default all three are true.  If
> > you configure a disk auxiliary, and if IsSpool is true
> for
> > the item, it will be spooled to disk per the disk
> usage
> > pattern.
> >
> > The default disk usage pattern sends items to disk
> only
> > when the memory store is full.  In contrast, the
> UPDATE
> > disk usage pattern will send all items to disk
> regardless of
> > whether or not there is room in memory.
> >
> > Your description is reversed.  If you are using the
> > LRU memory cache and if you have a size limit on the
> memory
> > of 100, the 1st item will be sent to disk when the
> 101st is
> > added, assuming that they were never accessed.  If
> the
> > 1st item was accessed after the 2nd was inserted or
> > accessed, then the 2nd will be spooled.  The least
> > recently used item will be spooled.
> >
> > Aaron
> >
> > --- On Mon, 12/28/09, GAMERMV@nationwide.com
> > <GAMERMV@nationwide.com>
> > wrote:
> >
> > > From: GAMERMV@nationwide.com
> > <GAMERMV@nationwide.com>
> > > Subject: question on isSpool=true
> > > To: "JCS Users List" <jcs-users@jakarta.apache.org>
> > > Date: Monday, December 28, 2009, 8:46 AM
> > > Here is a typical cache region
> > > configuration for us:
> > > jcs.region.lookupCache=DC2
> > >
> >
> jcs.region.lookupCache.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> > >
> jcs.region.lookupCache.cacheattributes.MaxObjects=100
> > >
> >
> jcs.region.lookupCache.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> > >
> >
> jcs.region.lookupCache.elementattributes=org.apache.jcs.engine.ElementAttributes
> > >
> >
> jcs.region.lookupCache.elementattributes.IsEternal=false
> > >
> >
> jcs.region.lookupCache.elementattributes.MaxLifeSeconds=500000
> > >
> jcs.region.lookupCache.elementattributes.IdleTime=1
> > >
> jcs.region.lookupCache.elementattributes.IsSpool=true
> > >
> >
> jcs.region.lookupCache.elementattributes.IsRemote=true
> > >
> >
> jcs.region.lookupCache.elementattributes.IsLateral=true
> > >
> > > 1. Can you confirm I am reading this correctly?
> > > a. Some cached data (anything over 100 objects
> but
> > within
> > > the
> > > MaxLifeSeconds) will spill to disk, due to
> IsSpool =
> > true
> > > b. Although IsRemote and IsLateral are both set
> to
> > true, it
> > > really does
> > > not mean that cache will be remote or
> synchronized
> > between
> > > multiple
> > > servers since none of these aspects are
> configured
> > >
> > > 2. Can you clarify the implications of cached
> data
> > > "spilling" over to
> > > disk? Once I have 101st object (in the example
> above)
> > that
> > > cache
> > > determines is going to be cached, does it  mean
> > that,
> > > when I as a user of
> > > this cache region do "getElement(101)", the
> caching
> > > framework will:
> > > a. Determine that 101 is not in the cache
> > > b. Send 1 LRUed object out to the disk cache
> (spill
> > > "cached" data to disk)
> > > c. Cache in memory element 101
> > >
> > > 3. If the above sequence of events is correct,
> can I
> > > presume that 2a, 2b,
> > > 2c will be executed synchronously (i.e. the call
> to
> > > getElement will be
> > > blocking until all a, b, and c operations are
> > complete)?
> > > asynchronously?
> > > Combination of thereof?
> > >
> > > Thank you
> > > Val
> > >
> >
> >
> ---------------------------------------------------------------------
> > 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
> 
> 

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


Mime
View raw message