Our caches cannot be in sync. We have a high traffic site and the client is afraid of too much cross talk. They have already turned off http session failover communication. Because of this we cannot broadcast puts.
Basically an admin tool sits on each instance. A user of the admin tool can delete an element from any cache on that instance. We need that delete message to be broadcasted to other instances in case they have that same element cached. In most cases the element will be cached on all instances, as there is a high amount of traffic. I was looking through the code and it seems like it would be straight forward to add a removeOnly attribute. I am more than willing to submit a patch. Let me know what you think. Thanks. Karl -----Original Message----- From: Aaron Smuts [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 1:07 PM To: 'Turbine JCS Developers List'; 'Baum, Karl' Subject: RE: [lateral cache] RemoveOnPutMode and localUpdate There was originally a web based admin tool. It is probably bundled with the extra stuff. I had an embedded server running and could manage and monitor each cache instance. I'm not sure what you need exactly. The lateral should be able to only broadcast remove messages. You want to be able to manage all the local caches from single spot without broadcasting puts? How would the control know what elements are in the locals if there was no broadcasting? I'm confused. Aaron > -----Original Message----- > From: Baum, Karl [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 7:38 PM > To: 'Turbine JCS Developers List' > Subject: RE: [lateral cache] RemoveOnPutMode and localUpdate > > That seems like a very useful option. We need something that will only > broadcast remove's to other instances. Basically we have an admin tool > which purges specific elements in caches. This admin tool sits in a > cluster. If a user removes an element on one instance, we need it to > replicate the remove to all other instances. However, we do not want > put's to be broadcasted. Does anybody know if this is currently > possible? > > -----Original Message----- > From: Todd Carmichael [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 10:48 AM > To: 'Turbine JCS Developers List' > Subject: [lateral cache] RemoveOnPutMode and localUpdate > > JCS developers, > I am working on adding RemoveOnPutMode functionality within the JCS > framework. Our team is building a web application that uses turbine, > torque > and jcs. I have been looking on how to extend the jcs TCP auxilary > lateral > cache to enable RemoveOnPut. I have made changes to LateralCache.java, > LateralCacheAttributes.java, and LateralCacheManager.java so that if the > cache is configured with the property: > > > jcs.auxiliary.LTCP.attributes.RemoveOnPutMode=true > > > Then the LateralCache will issue a remove instead of an update. This is > working mostly fine. I have also configured the lateral cache to use > PutOnlyMode to true. In this way, we only invalidate other caches if > the > object changes on the lateral cache on a particular server. I will > provide > these changes as a patch when I have completed testing. > > However, I am missing a piece. I need the ability add an item to the > cache > but not to broadcast that event to the other lateral caches. We need > the > ability to distinguish between an init or local update and an actual > change > to the item in cache. This would prevent a storm of network messages > that > would result as each server is loading up their cache items and > invalidating > the other lateral caches. If I am extending the idea of the lateral > cache > beyond what is intended, I would appreciate someone filling in the gaps > in > view of the design of the lateral and remote caches. Going on the > assumption that I would to perform a localUpdate on the cache, I do see > that > the CompositeCache.java class has the notion of a localUpdate method and > that would do the trick. However, the CacheAccess.java class, which is > the > layer to be used by jcs clients, does not expose the localUpdate > capability > in any methods. The only thing CacheAccess provides is a simple put. > My > thought was to extend the put method(s) in cache access to pass in a > flag > that would indicate that the update is local. Does that seem > reasonable? > Thoughts? > > Then lastly in torque I would change the AbstractBaseManager.java to > call > the update with the flag set if it has already found the item in its > cache. > > Thanks, > Todd Carmichael > > --------------------------------------------------------------------- > 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]
