qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-2565) Topic exchange may NPE during message routing
Date Sun, 26 Feb 2012 21:22:48 GMT

     [ https://issues.apache.org/jira/browse/QPID-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robbie Gemmell updated QPID-2565:
---------------------------------

    Component/s: Java Broker
    
> 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-subscribe@qpid.apache.org


Mime
View raw message