Ard Schrijvers wrote:
IIUC, EHCache allows you to set only the number of items in cache, and not
the maximum amount of memory to use, or minimum amount of free memory to
leave.
true (but the cache can't know the size of objects it gets stuffed with (you
say it is possible with java 1.5? ) )
No this information is not available, IIUC, via any published API.
In other words, EHCache leaves you up for guessing what the number should
be. It should not do this. Maximum number of items in memory should be
whatever memory can bear, and cache should dump unused memory once free
memory goes low.
I do not agree. This would imply a JVM always reaching max memory while this
is not necessary.
If there is a memory available to JVM you better make good use of it. What good
memory does if it is not used? Please clarify.
Think you are talking about a SoftReferences cache based,
No, SoftRefs are cleared in undefined order, which is not much better than
existing Janitor+EHCache combo.
but apart from some drawbacks, the eviction policy is very hard to implement
because you do not kwow which reference the jvm throws away.
Yep.
What I was talking about is using this Java 1.5 API:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryPoolMXBean.html#UsageThreshold
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryPoolMXBean.html#ThresholdNotification
It was on my TODO list for a long time now...
IMO, the cache configuration, like maxelements (memory) and maxdiskelements
should be modifable during run time, but, this is not possible with ehcache
or jcs.
No real objection here. But you would not need this if StoreJanitor functions
correctly.
Granted it can't be implemented cleanly in Java 1.4 (hence thread +
interval hack) but on Java 1.5 it would work beautifully. All you need is a
stinking API to clean out entries using LRU algorithm (or whatever is
chosen). Or just switch to Cocoon's cache in the meantime.
I haven't got problems with jcs if you know how large your stores can be
(crawler test and default sizes i have configured for different jvm mem
values).
That's exactly my point. You gotta spend non trivial amount of time tuning your
store configuration when this all can be done automatically by using correct SJ
implementation / caches.
Throwing away all cache experience of others and switch to cocoon
cache does't seem to make sense to me
Throwing away working system and jumping on incorrectly functioning
implementation is even worse :)
JCS will probably do the same. I guess that original purpose of
StoreJanitor was when Cocoon had its own store implementations
(transient, persistent) and we had to take care of cleaning
them up in our code.
It still does, and at the moment is easier to live with than EHCache -- as
shown by Ard in this email.
Jcs does not give me any problems (except headache in configuration :-) )
Exactly.
Vadim
