jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smuts, Aaron" <Aaron.Sm...@travelocity.com>
Subject RE: Serializing question about JCS in a Lateral Cache config
Date Fri, 09 Sep 2005 19:15:17 GMT
Can you explain to me what that means?  The os description you gave me
is extremely vague.  What is a flush event?  How does it know that
content is stale?

Does that mean when an item is expired and removed, then it is removed
from all?  JCS does that.

Are they ever sent to all the others?  If not then that sucks.

Basically you just want to broadcast removes, never try to get, and
never try to send?  

If you want to only send removes, then I'll have to expose a parameter
called allowPut.  You could set allowPut=false and allowGet=false, so it
could only remove.

What about if you put a new version of an item over an old?  Is that a
flush event?  Does that mean it is stale?

Then, you will need to check if an item exists before you put it in the
cache, if it does, call remove, then put it.  This way you could just
send invalidation messages.

Basic

> -----Original Message-----
> From: Zabel, Ian [mailto:IZabel@cirqit.com]
> Sent: Friday, September 09, 2005 11:29 AM
> To: 'JCS Users List'
> Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> Subject: RE: Serializing question about JCS in a Lateral Cache config
> 
> Aaron,
> 
> Thanks for putting so much thought into this!
> 
> What we would like to accomplish with our caching implementation is
> exactly
> what OSCache provides (described here:
> http://www.opensymphony.com/oscache/wiki/Clustering.html ).
> 
> Here is their description of their clustering:
> "Caches across a cluster only broadcast messages when flush events
occur.
> This means that the content of the caches are built up independently
on
> each
> server, but whenever content becomes stale on one server it is made
stale
> on
> them all. This provides a very high performing solution since we never
> have
> to pass cached objects around the cluster. And since there is no
central
> server that is in charge of the cluster, the clustering is very
robust."
> 
> This is the desired behavior in our application. Unfortunately, while
> OSCache meets our clustering needs, it does not meet our configuration
and
> tuning needs.
> 
> Is there any similar clustering configuration supported in JCS?
> 
> Any further insight or suggestion would be much appreciated!
> 
> Thanks,
> Ian.
> 
> 
> 
> -----Original Message-----
> From: Smuts, Aaron [mailto:Aaron.Smuts@travelocity.com]
> Sent: Friday, September 09, 2005 11:07 AM
> To: JCS Users List
> Subject: RE: Serializing question about JCS in a Lateral Cache config
> 
> 
> Thinking it over, I realized that the remove on put option doesn't
make
> sense for lateral cache clients and that's why it is not available.
> 
> It can result in extremely low hit ratios if you don't allow gets.
> 
> I can expose it, but you'd have to allow gets.  This would still
require
> you
> to distribute your objects.
> 
> Consider a scenario where there are two machines A and B.  They are
> connected by the lateral TCP plugin.  Each has the plugin set to issue
a
> remove rather than a put request to the other when an item is put into
the
> cache.  Also, each is not configured to get items from the other.
> 
> Element 1 is put into the cache on A.  A then issues a remove to B.  1
is
> requested on B.  B doesn't have it, so B creates 1 and puts it in the
> cache.
> B then issues a remove to A.  Element 1 is requested on A but it isn't
> present.  (back to the start) . . .
> 
> If the same element is needed on both machines, then you have to be
able
> to
> send it, either by puts or allow it to be retrieved.
> 
> The reason the remote cache had this option, was to prevent the
behavior
> of
> one machine from dominating the caches on the others.  When an item is
put
> in the cache that is a client of the remote server, the client send
the
> item.  The remote server then, by default, issues a remove request to
the
> other clients.  When a different client needs the item it can retrieve
it
> from the remote cache.
> 
> You cannot have a distributed cache that does not distribute items.
> 
> Aaron
> 
> 
> 
> > -----Original Message-----
> > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > Sent: Friday, September 09, 2005 10:34 AM
> > To: 'JCS Users List'
> > Subject: RE: Serializing question about JCS in a Lateral Cache
config
> >
> > Hey Aaron,
> >
> > Any update on this?
> >
> > Thanks,
> > Ian.
> >
> > -----Original Message-----
> > From: Aaron Smuts [mailto:asmuts@yahoo.com]
> > Sent: Sunday, September 04, 2005 9:00 PM
> > To: JCS Users List
> > Subject: RE: Serializing question about JCS in a Lateral Cache
config
> >
> >
> > It will take a few days.  Sorry.  I'll have it by
> > Thursday, hopefully.
> >
> > Aaron
> >
> >
> >
> > --- "Zabel, Ian" <IZabel@cirqit.com> wrote:
> >
> > > Hey Aaron,
> > >
> > > Have you made any progress on exposing the
> > > configuration option to issue
> > > removes?
> > >
> > > Thanks,
> > > Ian.
> > >
> > > -----Original Message-----
> > > From: Smuts, Aaron
> > > [mailto:Aaron.Smuts@travelocity.com]
> > > Sent: Wednesday, August 31, 2005 5:24 PM
> > > To: JCS Users List
> > > Subject: RE: Serializing question about JCS in a
> > > Lateral Cache config
> > >
> > >
> > > No.  The lateral sends objects.  It doesn't just
> > > issue remove requests by
> > > default.
> > >
> > > I'm not sure the configuration option to issue
> > > removes instead of requests
> > > is exposed.
> > >
> > > I will expose it tomorrow if it isn't already.
> > >
> > > I'm also working on a way to plugin a serializer, so
> > > if you wanted to use
> > > xstream, which doesn't require that your objects
> > > implement serializable,
> > > then you could.
> > >
> > > Aaron
> > >
> >
> >
> >
---------------------------------------------------------------------
> > 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