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.
Ultimately, our goal is to provide a JCache (http://www.jcp.org/en/jsr/detail?id=107) compliant cache API. 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.
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
