Hi!
I am using Commons Tx to handle a lot of small files in transactional
way with long term runs (weeks or days at least). New files arrives at
cca 100000 piece/hour. These files leaves the app at the end of
processing. We have noticed, that during work, the Commons Tx eates up
all heap memory (not confirmed yet, but I'm 90% sure about this
statement)...
Some investigation (profiling) pointed out, that in GenericLockManager,
the globalLocks Map just grows, and nobody removes lock entries. At
least lock instances multiples like viruses :)
I am aware that the supplied patch is probalby WRONG, but i am hoping to
reduce memory leak (is it leak?) even at some lock handling overhead
costs (the lock manager is now always reinserting locks).
Keep in mind, that a lot of new files enters and LEAVES my app, and will
never return to it. So, (at least in my case) the reuse of locks is not
as important as memory footprint reduction.
Thanx
~t~
Index:
/home/cstamas/worx/projects/ext/eclipse/commons-transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
===================================================================
---
/home/cstamas/worx/projects/ext/eclipse/commons-transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
(revision 348140)
+++
/home/cstamas/worx/projects/ext/eclipse/commons-transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
(working copy)
@@ -307,6 +307,8 @@
if (lock != null) {
released = lock.release(ownerId);
removeOwner(ownerId, lock);
+ // XXX to shrink the globalLocks map
+ removeLock(lock);
}
return released;
}
@@ -336,6 +338,8 @@
GenericLock lock = (GenericLock) it.next();
lock.release(ownerId);
locks.remove(lock);
+ // XXX to shrink the globalLocks map
+ removeLock(lock);
}
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
