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 Mon, 12 Sep 2005 20:28:33 GMT
Aaron,

I did some testing of OSCache, and I was incorrect. OSCache will only issue
flushes across the cluster when a remove() is called on the cache, _not_
when an object is updated.

I think with the allowPut=false and allowGet=false options, JCS would work
exactly as OSCache.

I noticed you have commited some code for an upcoming release candidate for
miscellaneous features. Will you be adding the allowPut config parameter at
some point after the RC release?

Ian.

-----Original Message-----
From: Zabel, Ian [mailto:IZabel@cirqit.com] 
Sent: Friday, September 09, 2005 6:07 PM
To: 'JCS Users List'
Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
Subject: RE: Serializing question about JCS in a Lateral Cache config


> This model runs into the problem I described earlier.  If the same 
> object is retrieved over and over on different machines, then it will 
> be deleted and inserted each time.  You'd potentially get a 0 hit rate 
> if the usage was identical on two nodes!

I might be completely missing your point, but retrieving an object from the
cache will not cause it to be deleted and inserted each time. Only when a
write occurs will the object need to be deleted and inserted. Assuming this
is true, and the usage of an application requires, conservatively, 20 reads
for every write, how would the 0 hit rate occur? Unless what you're talking
about is....

> If you described what a flush is in os, then the model of os is 
> extremely flawed.

I've only briefly looked into the OSCache code. It seems that different
types of events are triggered: FLUSH, ADDED, UPDATED, and REMOVED. In the
simple testing we did with OSCache, we didn't notice the problem you
described earlier where when an object is flushed from A, and then B loads
the object and causes A to flush, and so on. I'm not sure what magic they've
put in place to handle that scenario, but it certainly seems to work
correctly.

> I'll get the option in there.  It's simple.

Thanks again!

> The replication model is much more efficient.  Removes with gets is even
> better. . . .   JCS also allows you to setup nodes that can just
> broadcast but never receive.   . . .. 

Based on your input, we'll discuss this option and see if it fits in with
our app. 


Thanks,
Ian.

-----Original Message-----
From: Smuts, Aaron [mailto:Aaron.Smuts@travelocity.com] 
Sent: Friday, September 09, 2005 5:03 PM
To: JCS Users List
Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
Subject: RE: Serializing question about JCS in a Lateral Cache config




> -----Original Message-----
> From: Zabel, Ian [mailto:IZabel@cirqit.com]
> Sent: Friday, September 09, 2005 4:49 PM
> To: 'JCS Users List'
> Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> Subject: RE: Serializing question about JCS in a Lateral Cache config
> 
> In OSCache, a flush event seems to occur whenever a key is removed or
put
> into the cache.

This model runs into the problem I described earlier.  If the same object is
retrieved over and over on different machines, then it will be deleted and
inserted each time.  You'd potentially get a 0 hit rate if the usage was
identical on two nodes!



A Jgroups multicast is issued that contains the key that
> was
> flushed, and all listeners remove that key from the cache. This
handles
> putting a new version of an old object into the cache as well; a flush
is
> sent. I think I understand now that JCS doesn't have the idea of
> "flushes", but instead issues put, removes, and gets.
> 

If you described what a flush is in os, then the model of os is
extremely flawed.

> The configuration you proposed should be all we would need. Setting
> allowPut=false and allowGet=false should do the trick (as long as a
remove
> doesn't try to serialize the object across the lateral :). Our
abstraction
> layer would handle peeking into the cache first on a put and issuing a
> remove first.
> 

I'll get the option in there.  It's simple.

The replication model is much more efficient.  Removes with gets is even
better. . . .   JCS also allows you to setup nodes that can just
broadcast but never receive.   . . .. 

> 
> Thanks,
> Ian.
> 
> 
> -----Original Message-----
> From: Smuts, Aaron [mailto:Aaron.Smuts@travelocity.com]
> Sent: Friday, September 09, 2005 3:15 PM
> To: JCS Users List
> Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> Subject: RE: Serializing question about JCS in a Lateral Cache config
> 
> 
> 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.
> >

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