You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Peter Bugla <bu...@protosoft.de> on 2005/03/02 12:10:41 UTC
some problems found (and fixed) in jcs-1.2.4-dev
Hi,
I'm using Torque 3.1.1 (which is BTW still using jcs-1.0-dev.jar,
which is probably not a good idea) in a project.
We're currently try to squeeze out more performance from the
system, so I'm having a closer look at the Caching (apart from hundreds
of other things ;-).
As JCS obviously evolved since jcs-1.0-dev I started integrating
1.2.4 yesterday and stumbled over some problems.
During investigations I found some and solved one or the other things.
It's not working perfectly yet, but I thought I'd share what I found so far.
1.
org.apache.jcs.engine.control.CompositeCacheManager
If I understood the setting of this.props correctly
the method
public void configure(Properties props)
should have
this.props = props;
as the last line (currently missing).
Otherwise this.props is not set, which is of course bad.
2.
org.apache.jcs.engine.ElementAttributes.getTimeToLiveSeconds()
does not give back seconds, but milliseconds, therefor I'd say either the
name or the implementation should be changed.
I think I would simply correct the method to return seconds, as the level of
precision of milliseconds is very likely not required by anyone concerning
the
matter when a cache element expires and that precision would also be quite
difficult to get across the necessary calls without loosing one or another
of those
milliseconds during processing.
Corrcted:
public long getTimeToLiveSeconds()
{
long now = System.currentTimeMillis();
return ((this.getCreateTime() + (this.getMaxLifeSeconds() * 1000)) -
now) / 1000;
}
Don't forget to check and (if necessary) correct the logic of all places
calling this method.
3.
org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes.setMaxRecycleBinSize(int)
public void setMaxRecycleBinSize( int maxRecycleBinSize )
{
if( maxKeySize >= 0 )
{
this.maxRecycleBinSize = Math.min( maxRecycleBinSize, maxKeySize );
}
else
{
this.maxRecycleBinSize = DEFAULT_maxRecycleBinSize;
}
Calculating the value to actually put in this.maxRecycleBinSize based on the
value of maxKeySize
does not work, because you have no control over the order the values from
the cache.ccf
are processed by the PropertySetter (and I think it would not be a good idea
to introduce such a
dependency). So the current behavior is: maxRecycleBinSize is either the
value you specified
in cache.ccf, or maxKeySize, or the default, depending on the random order
the PropertySetter
processes the different configuration values.
I suggest to simplify the implementation and assume the guy changing
cache.ccf knows what
he's doing. If you think some additional information is needed to understand
the parameters
(would be a good idea to document them a bit more clearly, especially the
dependencies of
the parameters), that should be a documentation issue.
Working version:
public void setMaxRecycleBinSize( int maxRecycleBinSize )
{
this.maxRecycleBinSize = maxRecycleBinSize;
}
4.
(I'm not yet sure if that is a problem.)
If I specify
jcs.region.<my_region>.elementattributes.IsSpool=false
jcs.region.<my_region>.elementattributes.IsRemote=false
jcs.region.<my_region>.elementattributes.IsLateral=false
and the default region has these values set to true, they are ignored when
the cache is created.
org.apache.jcs.engine.control.CompositeCache
The constructor
public CompositeCache(String cacheName, ICompositeCacheAttributes cattr,
IElementAttributes attr )
stores the element attributes in this.attr, but it does take them into
consideration when creating the cache.
I think that might be okay, if the cache has some default behavior and my
specific region has some other
behavior, which is in this case checked, when the related actions take
place, e.g. if the time comes to
check if an element should be put to a remote cache, it is checked if the
element attributes permit that.
If that's not the case, it would be a problem.
What is strange for me however is that IsSpool, IsRemote, IsLateral are only
allowed
as elementattributes (not as cacheattributes), but they are stored (at least
for the default configuration
values) in CompositeCacheAttributes. I didn't expected that and I didn't get
the logic behind that so far.
Please let me know if I'm correct concerning 1, 2, 3
and let me know if 4 is a problem and how it works.
Thanks.
Do you already have a date planned for the next release?
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
Re: some problems found (and fixed) in jcs-1.2.4-dev
Posted by Aaron Smuts <as...@yahoo.com>.
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 <bu...@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" <as...@yahoo.com>
> To: "Turbine JCS Users List"
> <tu...@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
Re: some problems found (and fixed) in jcs-1.2.4-dev
Posted by Peter Bugla <bu...@protosoft.de>.
> 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" <as...@yahoo.com>
To: "Turbine JCS Users List" <tu...@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
Lateral TCP Cache config file for torque 3.1
Posted by Youngho Cho <yo...@nannet.co.kr>.
Hello,
I.m using torque-3.1.
I would like to use Lateral TCP cache with at least 2 more servers.
My config file is following.
But I couldn't sucessful to synchronize or invalidate the caches between 2 servers so far.
Is there something wrong in my configure file ?
If any one use Lateral Cache with torque, please post the config file.
I'm very appreciated.
Thanks,
Youngho
------------------------------------------------------------------------
# DEFAULT CACHE REGION
# sets the default aux value for any non configured caches
jcs.default=LTCP
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=2000
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
# this is copied from example, not sure of its utility
# SYSTEM CACHE
# should be defined for the storage of group attribute list
jcs.system.groupIdCache=
jcs.system.groupIdCache.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.system.groupIdCache.cacheattributes.MaxObjects=2000
jcs.system.groupIdCache.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
# DEFINE Lateral TCP Auxiliary Cache
jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.LateralCacheFactory
jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.LateralCacheAttributes
jcs.auxiliary.LTCP.attributes.TransmissionTypeName=TCP
jcs.auxiliary.LTCP.attributes.TcpServers=192.168.1.25:9112,192.168.1.12:9112
jcs.auxiliary.LTCP.attributes.TcpListenerPort=9111
jcs.auxiliary.LTCP.attributes.PutOnlyMode=true
# jcs.auxiliary.LTCP.attributes.PutOnlyMode=false
# jcs.auxiliary.LTCP.attributes.Receive=false
# CACHE REGIONS AVAILABLE
# Regions preconfigured for caching
jcs.region.com_nannet_jettiger_om_JettigerUser=LTCP
jcs.region.com_nannet_jettiger_om_JettigerUser.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.com_nannet_jettiger_om_JettigerUser.cacheattributes.MaxObjects=1200
jcs.region.com_nannet_jettiger_om_JettigerUser.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.com_nannet_jettiger_om_Preference=LTCP
jcs.region.com_nannet_jettiger_om_Preference.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.com_nannet_jettiger_om_Preference.cacheattributes.MaxObjects=1200
jcs.region.com_nannet_jettiger_om_Preference.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
Re: some problems found (and fixed) in jcs-1.2.4-dev
Posted by Aaron Smuts <as...@yahoo.com>.
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
--- Peter Bugla <bu...@protosoft.de> wrote:
> Hi,
> I'm using Torque 3.1.1 (which is BTW still using
> jcs-1.0-dev.jar,
> which is probably not a good idea) in a project.
>
> We're currently try to squeeze out more performance
> from the
> system, so I'm having a closer look at the Caching
> (apart from hundreds
> of other things ;-).
>
> As JCS obviously evolved since jcs-1.0-dev I started
> integrating
> 1.2.4 yesterday and stumbled over some problems.
>
> During investigations I found some and solved one or
> the other things.
> It's not working perfectly yet, but I thought I'd
> share what I found so far.
>
> 1.
> org.apache.jcs.engine.control.CompositeCacheManager
>
> If I understood the setting of this.props correctly
> the method
> public void configure(Properties props)
> should have
> this.props = props;
> as the last line (currently missing).
> Otherwise this.props is not set, which is of course
> bad.
>
> 2.
>
org.apache.jcs.engine.ElementAttributes.getTimeToLiveSeconds()
> does not give back seconds, but milliseconds,
> therefor I'd say either the
> name or the implementation should be changed.
>
> I think I would simply correct the method to return
> seconds, as the level of
> precision of milliseconds is very likely not
> required by anyone concerning
> the
> matter when a cache element expires and that
> precision would also be quite
> difficult to get across the necessary calls without
> loosing one or another
> of those
> milliseconds during processing.
>
> Corrcted:
> public long getTimeToLiveSeconds()
> {
> long now = System.currentTimeMillis();
> return ((this.getCreateTime() +
> (this.getMaxLifeSeconds() * 1000)) -
> now) / 1000;
> }
>
> Don't forget to check and (if necessary) correct the
> logic of all places
> calling this method.
>
> 3.
>
org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes.setMaxRecycleBinSize(int)
>
> public void setMaxRecycleBinSize( int
> maxRecycleBinSize )
> {
> if( maxKeySize >= 0 )
> {
> this.maxRecycleBinSize = Math.min(
> maxRecycleBinSize, maxKeySize );
> }
> else
> {
> this.maxRecycleBinSize =
> DEFAULT_maxRecycleBinSize;
> }
>
> Calculating the value to actually put in
> this.maxRecycleBinSize based on the
> value of maxKeySize
> does not work, because you have no control over the
> order the values from
> the cache.ccf
> are processed by the PropertySetter (and I think it
> would not be a good idea
> to introduce such a
> dependency). So the current behavior is:
> maxRecycleBinSize is either the
> value you specified
> in cache.ccf, or maxKeySize, or the default,
> depending on the random order
> the PropertySetter
> processes the different configuration values.
>
> I suggest to simplify the implementation and assume
> the guy changing
> cache.ccf knows what
> he's doing. If you think some additional information
> is needed to understand
> the parameters
> (would be a good idea to document them a bit more
> clearly, especially the
> dependencies of
> the parameters), that should be a documentation
> issue.
>
> Working version:
> public void setMaxRecycleBinSize( int
> maxRecycleBinSize )
> {
> this.maxRecycleBinSize = maxRecycleBinSize;
> }
>
> 4.
> (I'm not yet sure if that is a problem.)
> If I specify
>
>
jcs.region.<my_region>.elementattributes.IsSpool=false
>
>
jcs.region.<my_region>.elementattributes.IsRemote=false
>
>
jcs.region.<my_region>.elementattributes.IsLateral=false
> and the default region has these values set to true,
> they are ignored when
> the cache is created.
>
> org.apache.jcs.engine.control.CompositeCache
> The constructor
> public CompositeCache(String cacheName,
> ICompositeCacheAttributes cattr,
> IElementAttributes attr )
> stores the element attributes in this.attr, but it
> does take them into
> consideration when creating the cache.
>
> I think that might be okay, if the cache has some
> default behavior and my
> specific region has some other
> behavior, which is in this case checked, when the
> related actions take
> place, e.g. if the time comes to
> check if an element should be put to a remote cache,
> it is checked if the
> element attributes permit that.
> If that's not the case, it would be a problem.
>
> What is strange for me however is that IsSpool,
> IsRemote, IsLateral are only
> allowed
> as elementattributes (not as cacheattributes), but
> they are stored (at least
> for the default configuration
> values) in CompositeCacheAttributes. I didn't
> expected that and I didn't get
> the logic behind that so far.
>
>
> Please let me know if I'm correct concerning 1, 2, 3
> and let me know if 4 is a problem and how it works.
> Thanks.
>
> Do you already have a date planned for the next
> release?
>
>
>
>
---------------------------------------------------------------------
> 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