[
https://issues.apache.org/jira/browse/QPID-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPID-2565.
----------------------------------
Resolution: Cannot Reproduce
We were never able to reproduce this and so I will resolve this JIRA since we
dont currently envisage doing any changes as a result.
> Topic exchange may NPE during message routing
> ---------------------------------------------
>
> Key: QPID-2565
> URL: https://issues.apache.org/jira/browse/QPID-2565
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M4, 0.5, 0.6, 0.7
> Reporter: Robbie Gemmell
> Attachments: Qpid2565.java, Qpid2565Standalone.java
>
>
> Summary:
> The Topic exchange may generate an NPE during the message routing process, as
> seen in stack trace (comment below). 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
