> -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, February 16, 2002 10:51 PM > To: [EMAIL PROTECTED] > Subject: Re: JCS -- run time config / adding auxiliaries > > Okay, let me see if I have a handle on the configuration needs. It seems > that there are currently two sets of objects which need to be > configured. First, the regions which are available in the cache. Second, > the auxiliaries which are available to those regions. Every region and > auxiliary within the cache is identified by a unique ID. > > For a region users need to be able to configure > > 1. The id that identifies the region. > 2. The list of auxiliaries that should be used for the region, > possibly with a failover (or sequence of failovers) for each > auxilliary.
Later, auxiliaries like the remote cache server should have failover routes too. . . . > 3. The memory cache which should be used for the region. > 4. A set of cache attributes for the region. Currently the > configuration allows the user to define the class used to > contain the cache attributes, and the set of attributes to > populate it with. > > For an auxiliary one needs to be able to configure > > 1. The id that identifies the auxiliary. > 2. The class to use for the auxiliary. > 3. The attributes object to use for configuring the auxiliary. > 4. The actual attributes. > Yep. Yep. > > Two things immediately occur to me. The first is that the specification > of the class to use for attributes seems unnecessary, since there is > exactly one attributes class for each auxiliary, we can simplify > configuration by determining it at runtime. Ya. This makes sense. Would a naming convention do it? The current method was an easy way to implement it. Every factory takes an IAuxiliaryAttributes class. It was easy to just define the class in the props file. I'm not sure why anyone would want to change it unless they wanted to make one giant configuration class, but this would be a bleeding monster. It is harder to compiler enforce a naming convention than an interface, otherwise it sounds good and a bit less confusing. Second, that something like > the mapper might be an easy way to cleanup the configuration using XML. > However the mapper probably doesn't yet offer enough flexibility. > When it does . . > For regions, can the attributes class also be eliminated? In what > situations would one use something other than CompositeCacheAttributes? > I suppose it is configurable to allow more flexibility, but perhaps you > could elaborate on this area Aaron? I noticed the comment in > CacheAttributes says that it should probably be removed. Would it limit > flexibility for the Composite Cache ( Group Cache ? ) to be the only > option? Would seem to simplify things quite a bit conceptually. > CompositeCacheAttributes should be renamed CacheAttrbitues and the original CacheAttributes, if it isn't used should be scrapped. "Region" and "cache" are synonymous. Everything could be called "Region" but this is confusing. I really don't like that a Logger in log4j is called a category. It is much less confusing for me when it was called a Logger. > > I want to allow the cache to be programmatically configured. Right now, > > if a cache isn't configured in the cache.ccf, it will take the defaults. > > It would be nice if under certain conditions a program that wanted to > > add an auxiliary to a region could do so. > > I agree that that would be cool. If we created a standard public > interface for configuring the above things, then one could add regions > or auxiliaries to the cache, and assign auxiliaries to regions at > runtime. This would seem to be a good idea. The configuration mechanism > could use the same interfaces. It would be great if you could read a > configuration file at any time to add new modules to the cache. Hmmn. Not a bad idea. This would involve some deregistration to remote servers though. That should pretty much already be there, just need to call the methods. (maybe) > > > The easiest and cleanest way to do this would be to allow programs to > > get a list of auxiliaries that were in the props file and add or remove > > these from the particular cache region. > > Exactly. Really we need to divorce things from the props file at all. At > any given time we have a list of regions and auxiliaries in the cache, > which can be associated. Either programmatic configuration or reading of > another config file can be done at any time to add to those lists, or > add more associations. > It is nice to be able to define auxiliaries in the props file that are not currently used, so they can be added later. You don't know if they work until they are used. Right now the auxiliaries are only discovered when they are used. > > Anything more would be tricky. > > I don't know what more people would need, this should allow enough > flexibility. > > > I also wouldn't want people to be > > hardcoding configuration in their programs. This is what jcache > > proposes. It is easier for them since they have a fixed set of > > auxiliaries (disk and lateral), but JCS has an array of possibilities > > and they may not play well together. You wouldn't want two disk caches > > and you might have trouble running a remote and a lateral for the same > > region. This shouldn't cause any looping, but the behavior could be > > different. The remote coud be configured to remove upon put and the > > later to put on put. This might get funny and would be wasteful. > > Certainly there are bad configurations, but is it worth worrying too > much about preventing users from having two disk caches? I'm not preventing it. They can screw it up if they want. I'm mainly worried about people hard coding configuration parameters in their programs. These kinds of things are configuration dependent. Regions could be defined in a program and what auxiliaries they use, yes. Things like memory size and especially auxiliaries will change when an environment changes. The auxiliary list should definitely be defined in the props file. You couldn't move from dev, to qa, to production very easily otherwise . . . This would > probably be better accomplished with documentation and examples. I'm > inclined the best bet is to provide the simplest interface which offers > a nice amount of flexibility. > Yep. > > One thing that might be nice would be auxiliary failover switching. It > > would be cool to say use this auxiliary and if it goes into an error > > mode, start using this one. An xml config could handle this. The > > current configuration could do this in the list of auxiliaries. > > DC(JISP),RC(LC) -- use the indexed disk cache and iff it fails use the > > JISP. Use the remote cache and if it fails us the lateral cache . . . > > This wouldn't be so hard. > > > > Zombie mode you can detect this and switch. This might involve an > > internal wrapper over the auxiliaries that are added to the cache. > > These all seem like good ideas to me as we move forward. I like the idea > of being able to have more flexibility in configuring the cache. While > I'm not sure what the exact nature of the config files should be (I like > XML since there is a bit of hierarchy in the configuration) separating > the configuration of the cache from parsing of the config file, and > making the interfaces for the former public, seems like a good way to > accomplish what we need > This could turn into a huge job. For now to keep it simple we could: 1. Rename the CompositeCacheAttributes 2. Load up the auxiliary list in the base CacheManager. 3. Expose methods to get a list of auxiliary names and types. Perhaps this should be in a new class retrieved from the JCS access class. 4. Expose methods to set the auxiliary names for a region -- attachAuxiliaries( String [] names ). All current auxiliaries could be removed if they are not in the list. We many need to warn that this could be dangerous if the cache is currently very busy.(?) The attachAuxiliaries method could then lookup the auxiliary factory by the name factory configuration and then get an instance. 5. Make sure that part of the IAuxiliaryCache interface is deregistration or detach (better). I think destroy is currently used, but this kills the auxiliary in shutdown (which needs some work). One other thing: The memory cache uses the CompositeCacheAttributes (soon to be CacheAttributes) since the memory size needs to be configurable and there is no way to access the configuration classes of the auxiliaries. We might also want some methods to get to setAuxiliaryAttribute methods of the auxiliary caches, but this could come later. Aaron -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
