jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: some problems found (and fixed) in jcs-1.2.4-dev
Date Fri, 04 Mar 2005 05:06:00 GMT
I fixed 1 (setting the props in the manager), 2
(returing the time to live in seconds), and 3 (ending
the recycle bin size ambiguity).  I'll get them in
tonight.

The time to live seconds method is not used
internally. The adminBean does the same calculation
correctly.

About 4.  

JCS allows everything to be configured at the item
level, although you will almost always just take the
region defaults.  

You can setup a region with a disk cache, but you can
set some items as not spoolable.  This was sort of a
JSR107 idea.  Before that JCS just had region level
configuation settings.  I liked the idea of element
level settings.  

A region will most likely take the default element
attributes.  It should get these when it is
constructed.  

Thanks.  If you have any unit tests that expose the
configuration problems you found, please send them.

Aaron

--- Peter Bugla <bugla@protosoft.de> wrote:

> > Could we solve #3 by setting the max recycle bin
> size
> > when the key size is set too.
> 
> Well, you could of course have a flag for each of
> these values and check
> if it has been set already or not and do some
> calculation based on that.
> I wouldn't do that, because
> a) you run into the exact same problem when someone
> modifies the values 
> later
> (whatever value he sets first (let's say B) will be
> compared in the 
> calculation with
> the old value of the other parameter (lets say B).
> b) you don't really gain anything by that.
> 
> It's of course good to prevent the system from
> accepting wrong values as 
> early
> as resonably possible. I think in this case however
> it's not reasonable to 
> add such
> kind of checks in this place, as there's no chance
> to get it going without 
> introducing
> some very complicated concepts.
> 
> If you really want to do add such a kind of check,
> it would be much easier 
> and
> result in more understandable code by putting the
> plausibility checks 
> between
> different attributes in the place where they are
> still a Properties object. 
> At that time
> you have all parameters together and can run some
> plausibility checks 
> (probably even
> based on some restriction description file) and if
> necessary reject the 
> values with
> a meaningful message, e.g. "Some values are invalid:
> a must be greater than 
> b, c must not be 0".
> 
> If you ask me I would consider it sufficient in this
> case to throw an 
> exception stating
> which value or value combination is wrong (also
> stating, what's wrong, of 
> course),
> at the time the values are used.
> 
> > About 4. I may be misunderstanding your comments. 
>  .
> Yes, I think I was not clear enough.
> 
> If I put debug loggin on, I see that the element
> attribute values
> isSpool, isRemote, and isLateral of my region are
> not used in the
> construction of the cache (that may be fine so far,
> as they are
> element attributes values and not cache attribute
> values).
> 
> Where are these values for the construction of the
> cache
> taken from?
> Are they taken from the default element values?
> I wouldn't expect that, as these are also just
> element attributes.
> Are they taken from hardcoded cache values?
> Well, the log output is at least surprising then.
> 
> Looking at this from another side:
> Does it really make sense to have these attributes?
> As you specify the auxiliaries to use in the region
> specific cache.ccf 
> section
> anyway, e.g. "jcs.region.<my_region>=DC", which
> already states what caches
> to use, it does not make very much sense to me, to
> have an additional line
>
"jcs.region..<my_region>.elementattributes.IsSpool=true".
> If DC is a disk cache, JCS, could simply assume,
> that specifying a disk 
> cache
> for the reason might have the reason that it should
> be used. :-)
> 
> So probably it would make sense to remove the three
> attributes
> isSpool, isRemote, and isLateral from configuration
> altogether?
> 
> 
> ----- Original Message ----- 
> From: "Aaron Smuts" <asmuts@yahoo.com>
> To: "Turbine JCS Users List"
> <turbine-jcs-user@jakarta.apache.org>
> Sent: Wednesday, March 02, 2005 5:11 PM
> Subject: Re: some problems found (and fixed) in
> jcs-1.2.4-dev
> 
> 
> > Thanks for all the useful feedback.  I'll get to
> the
> > specifics soon.  We are int he process of moving
> JCS
> > up to a site level Jakarta project, so things will
> be
> > interrupted for a bit (a week or so).  I need to
> find
> > out when we are changing repositories before I put
> in
> > any patches.
> >
> > 1 and 2 should be easy to fix.  Thanks.
> >
> > Could we solve #3 by setting the max recycle bin
> size
> > when the key size is set too.
> >
> > About 4. I may be misunderstanding your comments. 
>  .
> > . . The isSpool, isRemote, isLateral settings are
> for
> > the elements because you control them at the
> region
> > level already by whether or not you decide to have
> a
> > disk cache, a lateral cache, or a remote cache.
> >
> > This just allows you to either have elements,
> let's
> > say, go to disk if a disk cache is available or to
> not
> > go to disk if one is available by default.  This
> > allows you to make going or not going an exception
> > case.
> >
> > I've never had reason to take anything but the
> > default.  If a region uses a disk cache then I let
> > everything go.
> >
> > This just give you a little more control.
> >
> > Aaron
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


Mime
View raw message