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: Okay next tqo quick questions...
Date Mon, 17 Aug 2009 13:57:58 GMT
I don't completely understand you setup.  But, if you remove an item from the cache, as you
might want to do with the old asset, it will be removed from all the auxiliaries.  If you
are using the indexed disk cache, it will be removed from the key map and the spot on disk
will be added to the recycle bin.  It will be reused if an item of equal or lesser size if
put on disk.  If no such item is ever put, then the gap can be removed during defragmentation
(if you configure the disk to optimize . . .)  

You might want to read through the docs and experiment a bit.  You'll get a better sense of
things.  All this is explained in the docs, at least, I hope it is.

Aaron

--- On Sun, 8/16/09, Jeffrey Kesselman <jeffpk@gmail.com> wrote:

> From: Jeffrey Kesselman <jeffpk@gmail.com>
> Subject: Re: Okay next tqo quick questions...
> To: "JCS Users List" <jcs-users@jakarta.apache.org>
> Date: Sunday, August 16, 2009, 11:01 AM
> Hi Aaron.
> 
> Thanks again for the help.
> 
> This is the issue. let me spell out my design and maybe you
> can either
> correct it or suggest how to accompish it.
> 
> I have resource-masters that store and server the actual
> resources and
> resource-clients that get from the master and use
> them.  The reource-clients
> cache locally to disk.  These cached values should
> stay until they are
> outdated by new versions of the same asset as asset
> download is expensive.
> 
> Client usage of resources is base on instructiosn
> sent  by the server,.
> Because I want to scale out massively for the clients, I
> ama voiding having
> the clients listen to puts of new resource versions. 
> Instead, when the
> server instructs the client o use an asset it oncludes a
> version number. If
> that version is not the one in teh cache, then the update
> is fecthed.  Im
> simualtign version numbers using JCS by coding the version
> number into the
> key-string.
> 
> Its worth notign this design ALSO nicely handles the issue
> of a client beign
> offlien whern an updated resoruce is pushed into the
> master.  Next time it
> is instructed to use it, it will go fecth it.
> 
> The issue is this:  Once I have a new version of an
> asset, I want to clear
> the old version OUT of the client disk cache.  It is
> garbage and  no lonegr
> needed and, over-time, this garbage coudl be quite
> significant in size.
> 
> The question is... how to garbage colelct the cache? 
> If I know when a new
> version is beignf etched, I can synthetically create the
> names of odler
> versions and make sure theya re deleted.  This was my
> first thought and the
> genesis of my question about checkling to see if something
> is in the cache
> before it is fecthed.
> 
> ANOTHER approach would be to walk through all the current
> locally stored
> cache keys and delete any entreis for which there ar mroe
> recent versions.
> (Again, i can determine this through the key-name
> conventions.)  Is this
> dioable?
> 
> On Sun, Aug 16, 2009 at 10:23 AM, Aaron Smuts <asmuts@yahoo.com>
> wrote:
> 
> >
> >
> > --- On Fri, 8/14/09, Jeffrey Kesselman <jeffpk@gmail.com>
> wrote:
> >
> > > From: Jeffrey Kesselman <jeffpk@gmail.com>
> > > Subject: Okay next tqo quick questions...
> > > To: "JCS Users List" <jcs-users@jakarta.apache.org>
> > > Date: Friday, August 14, 2009, 3:55 PM
> > > (1)  Why does CacheAccess.get()
> > > return an Object and not a Serializable.
> > > Doesn't any object stored in the cache have to be
> a
> > > Serializable?
> > >
> >
> > The original ICacheAccess interface take and returns
> objects.  The idea was
> > that the cache should be usable with just memory
> auxiliaries.  So we
> > shouldn't restrict to Serializable.  However,
> nearly every other auxiliary
> > requires it.  . .  .
> >
> > > (2) If i call get(...) on my remote cache and the
> object
> > > isnt there, it will
> > > attempt to fetch iot from its server yes? 
> is there
> > > some way for me to know
> > > this is happening? some kind of .contains(...)
> call I could
> > > call first or
> > > something?
> > >
> >
> > You call get on a local cache.  It it is not
> present locally, the remote
> > cache client will call get on the remote cache
> server.  If the server
> > doesn't have it, it will do the same thing.  If
> the server is configured
> > with a failover, it will call get on the failover.
> >
> > You don't have anyway to know before calling get what
> will happen
> > underneath.  What would the contains method
> do?  I don't understand.
> >
> > Aaron
> >
> > > --
> > > ~~ Microsoft help desk says: reply hazy, ask
> again later.
> > > ~~
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> >
> >
> 
> 
> -- 
> ~~ Microsoft help desk says: reply hazy, ask again later.
> ~~
> 

---------------------------------------------------------------------
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