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