Topic exchange may NPE during message routing
---------------------------------------------
Key: QPID-2565
URL: https://issues.apache.org/jira/browse/QPID-2565
Project: Qpid
Issue Type: Bug
Affects Versions: 0.6, 0.5, M4, 0.7
Reporter: Robbie Gemmell
Fix For: 0.7
Summary:
The Topic exchange may generate an NPE during the message routing process, as
seen in IBAMQ-1344. It is believed this can only be attributed to 'undefined
behaviour' defined in the map.Entry Javadoc, which may be exhibited by
Map.Entry objects returned from an Iterator over the keySet() and entrySet()
results of a ConcurrentHashMap in the event the map is updated directly
following generation of the Map.Entry. The code section in question should be
updated to remove use of Map.Entry since its behaviour in this case cannot be
guaranteed otherwise without additional locking that would hinder performance
of the exchange.
Additional Detail:
It hasnt been possible to reproduce the error thus far, and at first glance it
was believed the code in question should never be able to NPE, as none of the
methods should be able to return null based on the fact they either return a
new Set() or a key/value that can never be null, as null can never be entered
into the map.
However, searching the Sun JDK BugDatabase revealed a historical instance (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6312056 ) where the
Map.Entry.value() did return null, and although this case was fixed the report
also draws attention to the fact that usage of Map.Entry's returned by the
Iterator from a ConcurrentHashMap are not completely safe, and may exhibit
'undefined behaviour' if the Map is modified thereafter via any means other
than the map.Entry itself, despite the fact the Iterator itself is safe in such
cases.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Map.Entry.html states:
"These Map.Entry objects are valid only for the duration of the iteration; more
formally, the behavior of a map entry is undefined if the backing map has been
modified after the entry was returned by the iterator, except through the
setValue operation on the map entry. "
The NPE occurs on the last line of the following code section:
for(Map.Entry<AMQQueue, Map<MessageFilter<RuntimeException>, Integer>> entry :
_filteredQueues.entrySet())
{
if(!queues.contains(entry.getKey()))
{
for(MessageFilter<RuntimeException> filter : entry.getValue().keySet())
The _filteredQueues map is a ConcurrentHashMap, itself containing
ConcurrentHashMap values. It is not possible for a null to be used as either
key or value in a CHM, and both keyset() or entrySet() return a new Set if none
previously existed. As a result it would seem that it should not be possible
for the above line to ever contain a null unless due to the aforementioned
undefined behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
