On Mon, 30 Aug 2004 21:55:21 -0600, Bruce Snyder wrote: > >Gregory Block wrote: > >> It would be nice if we included the oswego concurrency library and moved >> to ReadWriteLock API for operations like this. >> >> Also, sidenote: I've just done some perf analysis on our staging server >> and found some pretty hefty inefficiencies in the TimeLimited cache. >> (We use a low 10sec cache on some; larger on others) >> >> - TickThread is reported as using an awful lot of CPU; >> - It seems to spend that time iterating. >> - Iterating through hashtables is a bad thing in general. >> >> So, I've got two suggestions. >> >> 1) Move to ehcache implementation for our caches; it's a >> high-performance cache, and it's pretty good at this kind of stuff. >> Introduces a jar, but I'd almost rather have another jar than our >> current implementation... >> >> or 2) I can provide a hacked up version of a conveyor belt >> implementation of TimeLimited; we've got a conveyor belt API which >> should be 1.2/1.3 compatible which we've hacked on just for the purposes >> of getting a good performance out of large collections of time-limited >> objects. Basically, the conveyor belt contains n containers; items >> always go into the first container on the belt. Timer events go off >> every (cache-time/buckets); when the timer event goes off, everything >> moves over by one; a new bucket goes on to the front of the conveyor >> belt, where new objects go, and one drops off the end, >> which goes to a destructor and then to the garbage collector to gc. >> When you ask for something out of the cache, you ask all the buckets on >> the belt; >> when something goes in, you verify that it isn't already in one of those >> buckets. >> >> It's quick, it's painless, it's low-cpu, and it makes disposal nearly >> free. On the other hand, your time granularity isn't "exactly" n - it's >> n to the nearest timer event. It's close, though. >> >> Someone can decide whether to do 1, 2, or leave it the way it is. (I'd >> prefer *not* to leave it the way it is.) > >Gregory, > >I would prefer the Oswego util.concurrent libarary. Yes, it is another >third party dependency but only prior to J2SE 1.5. It's actually >integrated into J2SE 5.0. We can get around this via the Ant build (e.g. >J2SE < 5.0 uses the Oswego util.concurrent library whereas J2SE => 5.0 >uses the java.util.concurrent libarary (unless there are clashes with >old and new)) quite easily.
+1. Gregory, can you please open a new bug report. >Ultimately, our goal is to provide a JCache >(http://www.jcp.org/en/jsr/detail?id=107) compliant cache API. Please see some bug (I cannot remember the number right now .. :-( ) for progress on this. >I would >be in favor of offering your solution two above as a configurable option >to Castor users via the castor.properties file. All we need to do is >give it a unique name. +1 as well. And whilst we are talking about this, I think we should add the TimeLimited implementation by Stein as well (though this is JDK 1.3 and above), but once again with Ant things can be done. Werner > >Bruce >-- >perl -e 'print >unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");' > >The Castor Project >http://www.castor.org/ > >Apache Geronimo >http://incubator.apache.org/projects/geronimo.html > > > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
