jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smuts, Aaron" <aaro...@amazon.com>
Subject RE: Excessive number of JCS objects in memory
Date Thu, 03 Feb 2005 21:29:57 GMT
The published source x ref is out of date, but you can browse the repository here:

http://cvs.apache.org/viewcvs/jakarta-turbine-jcs/ 


I can't get cvsgrab 2.1 to work either.  I had cvsgrab working in August.

Aaron


-----Original Message-----
From: Wyatt, Allen [mailto:Allen.Wyatt@travelocity.com] 
Sent: Thursday, February 03, 2005 11:51 AM
To: Turbine JCS Users List
Subject: RE: Excessive number of JCS objects in memory

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


---------------------------------------------------------------------
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