jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wyatt, Allen" <Allen.Wy...@travelocity.com>
Subject RE: Excessive number of JCS objects in memory
Date Thu, 03 Feb 2005 19:50:40 GMT
Is there a zip file of the source code for 1.2.4 somewhere?  I'm having
a hard time getting the source code from behind the company firewall
(haven't been able to get CVSgrab to work). 

-----Original Message-----
From: Smuts, Aaron [mailto:aaronsm@amazon.com] 
Sent: Thursday, February 03, 2005 1:18 PM
To: Turbine JCS Users List
Subject: RE: Excessive number of JCS objects in memory

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:Allen.Wyatt@travelocity.com] 
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: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
turbine-jcs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
turbine-jcs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


Mime
View raw message