jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hanson Char <hanson.c...@gmail.com>
Subject Re: Serializing question about JCS in a Lateral Cache config
Date Mon, 12 Sep 2005 21:28:07 GMT
But it's incorrect to rely on hashcode to determine if two objects have the 
same value. Two objects can be completely different but have the same 
hascode. (Even md5 is broken for that matter). My 2 cents.

Hanson

On 9/13/05, Smuts, Aaron <Aaron.Smuts@travelocity.com> wrote:
> 
> I'm going to put those options in yes. I'll have them in a few days.
> It's fairly easy.
> 
> Also, I'm going to add remove on put for the client. It will pass in
> the hashcode of the object. If configured, the receiver can compare the
> hashcode of the item to remove with the hashcode passed in. If they are
> the same, it will assume that the object has the same values, and it
> will not remove it. This will solve the evil remove-get-remove-get
> problem I describe previously. You will have the option to make this
> work by providing a useful hashcode function.
> 
> > -----Original Message-----
> > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > Sent: Monday, September 12, 2005 4:29 PM
> > To: 'JCS Users List'
> > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > Subject: RE: Serializing question about JCS in a Lateral Cache config
> >
> > 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
> 
> ---------------------------------------------------------------------
> 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