Hi Karls
The still seems to be a memory leak, after running for a while I've
thousands of live instances of Permissions and of Permissions#Entry. The
problem seems to be related to the cache-maps in Permissions.
Disabling the static cache with the following:
private static final Map m_permissions = new AbstractMap() {
public Set entrySet() {
return new HashSet();
}
public Object put(Object key, Object value) {
return null;
}
};
"fixes" the memory leak.
I've not yet understood why the cleaning of the cache with the
ReferenceQueue isn't working as expected.
One thing I don't understand with m_permissionCache is why addToCache()
creates a soft-reference with the non-static m_queue as
ReferenceQueue, but I don't think this is related with the problem as
the allocations that do not get eligible for garbage-collections are
instantiated in Permissions.getPermissions().
What seems to be wrong is the m_permissions.get(permissionInfos) in
Permissions.getPermissions() which should be m_permissions.get(new
Entry(permissionInfos)), but this odesn't solve the problem of the
continuosly growing m_permissions.
Another thing I don't understand are why this HashMaps with the
weak-references as key are used and not WeakHashMap().
Regards,
reto
Karl Pauls said the following on 01/28/2009 01:28 AM:
> Thanks. Fixed in trunk (as of revision 738319).
>
> regards,
>
> Karl
>
> On Tue, Jan 27, 2009 at 2:13 PM, Reto Bachmann-Gmür
> <[email protected]> wrote:
>
>> Due to a wrong implementation of equals in Permissions.Entry m_cache
>> gets bigger and bigger. A fix is to replace line 180 of Permissions.java
>> (in org.apache.felix.framework.security.util) with the following:
>>
>> if (o instanceof Entry) {
>> return entry.equals(((Entry)o).get());
>> } else {
>> return false;
>> }
>>
>> Regards,
>> Reto
>>
>> ---------------------------------------------------------------------
>> 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]
