RE: HELP - very weird behaviour - solved

[Vladimir Olenin <VO...@cihi.ca>]

Ok. This has to be put somewhere Wiki. The problem was in a missing
logging configuration. It seems to be the SLF4J bug, since 'standard'
commons-logging.jar implementation doesn't give this problem.

For the record, below is the configuration, which caused the problem:

- SLF4J implementation of Commons Logging:
  - jcl104-over-slf4j.jar
  - slf4j-log4j12.jar
- Log4J library
  - log4j-1.2.8.jar
- JCS library:
  - jcs-1.2.7.9.jar
- log4j.properties file is NOT present

This results in the following two (standard) warning lines from log4j
output to the console at application startup:

log4j:WARN No appenders could be found for logger
(org.apache.jcs.engine.control.CompositeCacheManager).
log4j:WARN Please initialize the log4j system properly.

If log4j is configured properly OR commons-logging.jar file is used as
CommonsLogging implementation, then everything works as expected.

Thanks everyone for help!

-----Original Message-----
From: Vladimir Olenin [mailto:VOlenin@cihi.ca] 
Sent: Friday, August 25, 2006 10:39 AM
To: JCS Users List
Subject: RE: HELP - very weird behaviour

Thanks. I've checked you suggestions, just to be on the safe side, but
GC is definitely not an issue. ALL serialized structures I put into
cache take at most 5M. The GC output shows only Young generation
collections, which are fast (< 0.004). The JVM params used are:
-verbose:gc -server -Xms64M -Xmx64M  -Xloggc:gc.log -XX:GCTimeRatio=19

0.000: [GC 5824K->1725K(64832K), 0.0164626 secs]
0.449: [GC 7549K->2593K(64832K), 0.0203206 secs]
0.593: [GC 8417K->2362K(64832K), 0.0067281 secs]
0.795: [GC 8186K->2620K(64832K), 0.0069210 secs]
0.987: [GC 8444K->2820K(64832K), 0.0069212 secs]
1.221: [GC 8644K->3158K(64832K), 0.0060625 secs]
1.356: [GC 8982K->3434K(64832K), 0.0086940 secs]
1.645: [GC 9258K->3786K(64832K), 0.0065196 secs]

The gc output & behaviour does NOT seem to differ depending on the
'MaxObjects' parameter...

Any other insights?.....

Vlad

-----Original Message-----
From: Hanson Char [mailto:hanson.char@gmail.com]
Sent: Thursday, August 24, 2006 7:38 PM
To: JCS Users List
Subject: Re: HELP - very weird behaviour

Can GC, heap memory min/max sizes, and the GC throughput target be some
factors ?  What JVM are you running on ?  If Java 5, you can try some of
these JVM parameters:

-server for server mode
-verbose:gc to find out more about what the GC is doing
-XX:+UseParallelGC for concurrent GC
-XX:GCTimeRatio=19 for the target throughput rate (default is 99)
-Xms512m -Xmx512m  for the min/max heap memory size

For example:

java -server -verbose:gc -XX:+UseParallelGC -XX:GCTimeRatio=19 -Xms512m
-Xmx512m Main

My 2 cents.

Hanson

On 8/24/06, Vladimir Olenin <VO...@cihi.ca> wrote:
> Hi,
>
> I'm using the following configuration:
>
> ----------------------------
> jcs.default=DC
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttrib
> ut
> es
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memo
> ry
> .lru.LRUMemoryCache
>
>
> # AVAILABLE AUXILIARY CACHES
> jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCach
> eF
> actory
> jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Inde
> xe
> dDiskCacheAttributes
> jcs.auxiliary.DC.attributes.DiskPath=./temp
> jcs.auxiliary.DC.attributes.maxKeySize=100000
> jcs.auxiliary.DC.attributes.MaxPurgatorySize=100000
> ------------------------
>
> The weird thing is that the entries retrieval performance degrades 
> when 'jcs.default.cacheattributes.MaxObjects' grows. I assumed it 
> should be the other way around. When I set this value to '10000' and 
> put not more than '10000' entries in cache, the jcs.get(key) start to
CRAWL!!!
> (returns within 2-3 seconds) with CPU consumption at 100%. The 'data'
> and 'key' files are empty, which seems to prove that all entries are 
> contained in memory and nothing has been swapped to HD.
>
> When that setting is at '10', 'data' and 'key' files are growing to 
> several megs (with my data), which seem to prove that almost all 
> entries are swaped to HD, while jcs.get() call returns within serveral

> milliseconds.
>
> What am I doing wrong?...
>
> Thanks.
>
> Vlad
>
>

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


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


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