RE: Excessive number of JCS objects in memory

[Smuts, Aaron]

Take a quick look at the latest source code (1.2.4-dev release).  The old 
ReadWriteLock is no longer used (I think anywhere in JCS).  

A while back, the indexed disk cache used to share the lock with the abstract 
disk cache.  I think we were sharing locks for a number of reasons.  Using the 
locker in the base class allowed us to make sure that purgatory elements got to 
disk if they were not retrieved first, and didn't get to disk if they were.  We 
locked on the key in order speed things up.  

We stopped removing items from purgatory if they were retrieved.  We used to do 
this to avoid an unnecessary write.  However, this made it inefficient to run 
with 0 items in memory.  Now we do not remove items from purgatory if they are 
found there on a get.  This made things more simple.  

We no longer needed to share the locks at this point, so we changed the lock 
manager to the util concurrent lock.  The abstract disk cache shoulf have been 
changed too.

After you noticed the rwlock leak, I changed the abstract disk cache to simply 
syncrhonize in blocks dealing with purgatory items.  It could probably be made 
cleaner, but there do not seem to be any problems with the way it is now.  I'm 
still going over it, but all my tests are passing with the 1.2.4 code.

Aaron

-----Original Message-----
From: Wyatt, Allen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 02, 2005 4:15 PM
To: Turbine JCS Users List
Subject: RE: Excessive number of JCS objects in memory

I may have discovered what is causing a leak of ReadWriteLock and RwLockHolder 
objects (both in package org.apache.jcs.utils.locking).

Each cache region that uses an auxiliary disk cache has its own 
IndexedDiskCache.  Each AbstractDiskCache (from which we get
IndexedDiskCache) has its own ReadWriteLockManager to manage locking stuff.  
Each ReadWriteLockManager has its own locks Hashtable keyed by String ids with 
RwLockHolder values.  All ReadWriteLockManagers share one RwLockGC (it's a 
static member of ReadWriteLockManager) to clean up locks.  The RwLockGC gets 
created once with a reference to one ReadWriteLockManager's locks Hashtable.  
If I'm looking at this correctly, that means the other ReadWriteLockManagers' 
locks Hashtables are not under the control of the RwLockGC cleaner thread and 
so the RwLockHolders (which hold ReadWriteLocks) in those locks Hashtables 
never get cleaned up.

Does this look right?  If so, how would we fix this?  Would it be possible to 
have all ReadWriteLockManagers share one locks Hashtable?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]