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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> wrote: > > > Hey Aaron, > > > > Have you made any progress on exposing the > > configuration option to issue > > removes? > > > > Thanks, > > Ian. > > > > -----Original Message----- > > From: Smuts, Aaron > > [mailto:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
