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 Wed, 02 Mar 2005 16:11:23 GMT
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 <bugla@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


Mime
View raw message