jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zabel, Ian" <IZa...@cirqit.com>
Subject RE: Serializing question about JCS in a Lateral Cache config
Date Fri, 09 Sep 2005 15:29:16 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message