jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Bugla" <bu...@protosoft.de>
Subject Re: some problems found (and fixed) in jcs-1.2.4-dev
Date Thu, 03 Mar 2005 10:30:35 GMT
> 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


Mime
View raw message