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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
