> 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? ) ) > > 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. Think you are talking about a SoftReferences cache based, but apart from some drawbacks, the eviction policy is very hard to implement because you do not kwow which reference the jvm throws away. IMO, the cache configuration, like maxelements (memory) and maxdiskelements should be modifable during run time, but, this is not possible with ehcache or jcs. > > 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). Throwing away all cache experience of others and switch to cocoon cache does't seem to make sense to me > > > > 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 :-) ) > > Vadim > >
