Michał Pachucki created CXF-7824:
------------------------------------
Summary: CacheMap may have spurious null keys
Key: CXF-7824
URL: https://issues.apache.org/jira/browse/CXF-7824
Project: CXF
Issue Type: Bug
Affects Versions: 3.2.6
Reporter: Michał Pachucki
Hello,
I was debugging a bug in my code and by accident I found a bug in CacheMap.
The function updateMainDataMap copies elements from extraKeyMap to mainDataMap
but does not make sure that keys are not null.
It is possible that entrySet of WeakIdentityHashMap will return null keys.
{code:java}
public Set<Map.Entry<K, V>> entrySet() {
reap();
Set<Map.Entry<K, V>> ret = new HashSet<Map.Entry<K, V>>();
for (Map.Entry<IdentityWeakReference, V> ref : backingStore.entrySet()) {
final K key = ref.getKey().get(); //possible null here
final V value = ref.getValue();
Map.Entry<K, V> entry = new Map.Entry<K, V>() {
public K getKey() {
return key;
}
public V getValue() {
return value;
}
public V setValue(V value) {
throw new UnsupportedOperationException();
}
};
ret.add(entry);
}
return Collections.unmodifiableSet(ret);
}{code}
On entrance the function clears all null keys (in the reap() functon) and then
iterates over backingStore. But it is possible that after reap() a key is
garbage collected and its WeakReference will return null (ref.getKey().get()).
This causes a spurious null key.
I gave this case a Major priority because this class is used by
WSDLManagerImpl, and spurious null keys cause serious problems there. I can
reproduce this problem in a few minutes of testing. The testcase consists of
creating generated service over and over again by multiple threads.
Unfortunately the testcase itself is too big to share.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
