good idea. +1
On 11/2/06, Thomas Mueller <[EMAIL PROTECTED]> wrote:
Hi, Just recently I experienced an out of memory problem with Jackrabbit. I analyzed the memory usage and found the problem is the combined size of the various caches of Jackrabbit, and other libraries (Lucene, the database, and others). The biggest problem was the combined size of the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create a few (?) of those caches, and each one is limited to 4 MB by default. At one point, I had 16 of those. 64 MB is not that much, but if you only allocate 128 MB it is already a problem. It is possible to change the size limit (by changing DEFAULT_MAX_MEM), but this means the biggest one can get at most this amount of memory. I think that would be good is some kind of dynamic (cache-) memory management. A single service that distributes the available memory (or at least some fixed amount) dynamically to all those caches (let's call it CacheManager). This could be per-repository, or a singleton. It would keep a weak reference to all caches. If a new cache is created, the cache manager would give him some minimum amount of memory (let's say 128 KB), and if the cache is used frequently, it would get more memory. The cache manager would shrink caches that are not used frequently. I suggest to implement such a singleton CacheManager. Currently just for MLRUItemStateCache, as this seems to be the biggest problem so far. Later on (if we think it's worth doing it), it could be extended to other caches as well. Maybe such a service already exists somewhere (apache commons?) Please tell me if you know of any such service. If not, I will go ahead and implement such a feature, unless there are other ideas. Thomas
-- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
