-
I've had three expiration policy issues related how date-created and date-last-accessed are used (forgive me, I don't have the source/doc's in front of my, so the names are aliases)
My understanding is that
max-age relates to date-created and is set on every put and is immutable.
max-idle relates to date-last-accessed which is set on every successful get.
However, the max-idle can...
2009-08-09 12:41:54 UTC in ehcache
-
I've created an implementation of a 32 random sampling LRU,LFU,FIFO 'CompactConcurrentMap' which is modeled on ConcurrentHashMap but adapted for non Object elements.
Initial benchmarks put it at with 25% as fast as CHM. Theoretically it can flat out replace half the ehcache operations, since expiration is embeded within the core code, though it has no disk-store capability.
I still am...
2009-08-08 20:20:18 UTC in ehcache
-
Yes and no. I've had similar interests. The easiest is to run the full hibernate mapping in app2, BUT use a different ehcache configuration such that only the interested entities participate in the cluster. Also use a read-only database connection in app2 for the hibernate Session.
This will guarantee you cache-coherence, because you can always pull from the DB on a cache miss.
You do...
2009-07-19 21:07:50 UTC in ehcache
-
11) Garbage collection
It's possible to produce a thread-safe linked-list of of elments, a LinkedHashMap without all the complexity of the google LRU ConcurrentHashMap. This isn't an LRU, it's just a LIFO-style LinkedHashMap. Note, a FIFO could also be possible, but as you'll see, it's not necessary.
AtomicReference<Element> head;
while (true) {
el.next = head.get();
if...
2009-07-18 12:59:56 UTC in ehcache
-
Sub-subject: LRU/LFU/FIFO 30-sample calculation performance issue.
So I tested out the new 1.6 LRU with array-keys (cache-size > 5k) v.s. linear walks of the ConcurrentHashMap. And it's performance collapsed as I speculated.
ConcurrentHashMap is fast for gets/puts, but sucks a$$ for iterators.
If I create ehcaches of max-size 100, 1k, 4k, 10k, 400k and 510k all with 500k...
2009-07-17 16:11:17 UTC in ehcache
-
More DiskStore optimizations (item 6)
It occurred to me that a disk-cache doesn't have to be as rigorous as an in-mem cache, and thus we can allow slightly random expirations at the expensive of memory space. Namely work like a CPU cache which expires elements on collisions.
Namely you have key.hashCode().. You also have whether the key can serialize or not. If not, you have to keep...
2009-07-17 15:44:34 UTC in ehcache
-
Sorry, still need more information.
100 http req/sec is nothing.
cached gets are independent of the network / RMI layer as they happen in peer threads (except when in synchronous mode). And ehcache can do 100k+ gets / sec (easily) and 10k+ puts / sec (in diskless/networkless mode, slightly slower in networked mode). And moreover, the network-layer threads are ONLY busy when there's...
2009-07-15 18:38:27 UTC in ehcache
-
So the question is, for each cache, what type of data constraints do you have.
Good rules of thumb I've found (others may want to add - dispute):
1) If data is generated uniquely on nodeA and must be present on all nodes thereafter, then obviously puts/updates via copy is needed. If nodeB is unlikely to be used (e.g. only for fail-over), then async can be used, otherwise sync is needed...
2009-07-15 16:31:20 UTC in ehcache
-
I can't imagine JMS ever having higher performance than RMI or jgroups natively. You still need to [de]serialize, synchronize (or monitor), queue and distribute the messages. If the JMS platform is a 3'rd party process, then you have even higher network overhead. Further, some JMS platforms journal to disk and may block once their max-in-mem is reached.
I'm not an ehcache developer but...
2009-07-13 15:19:59 UTC in ehcache
-
I already noticed a few corrections needed from my post:
2) current code uses a HashMap to continue operating while the background thread is sleeping/processing, thus a queue isn't appropriate for the elements. I've found blocking-queues produce the simplest and most reliable code. So one approach is to use a queue + synchronized HashMap, whereby you clear the queue instead of swapping, and...
2009-07-09 13:20:48 UTC in ehcache
