[ 
https://issues.apache.org/jira/browse/STORM-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137192#comment-14137192
 ] 

ASF GitHub Bot commented on STORM-497:
--------------------------------------

GitHub user revans2 opened a pull request:

    https://github.com/apache/incubator-storm/pull/257

    STORM-497: don't modify the mapping while the someone could be reading it.

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/revans2/incubator-storm STORM-497

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-storm/pull/257.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #257
    
----
commit f259f1da288171a9393fb500150d034ccca0d146
Author: Robert (Bobby) Evans <[email protected]>
Date:   2014-09-17T13:07:42Z

    STORM-497: don't modify the mapping while the someone could be reading it.

----


> b.s.m.netty.Server.getMessageQueueId is not thread safe, and can return null
> ----------------------------------------------------------------------------
>
>                 Key: STORM-497
>                 URL: https://issues.apache.org/jira/browse/STORM-497
>             Project: Apache Storm (Incubating)
>          Issue Type: Bug
>    Affects Versions: 0.9.3-incubating
>            Reporter: Robert Joseph Evans
>            Priority: Critical
>
> b.s.m.netty.Server.getMessageQueueId
> https://github.com/apache/incubator-storm/blob/c5c3571ca15ee2dd675fb3cac44bd0f926ccfc67/storm-core/src/jvm/backtype/storm/messaging/netty/Server.java#L132-150
> If there is contention when updating taskToQueueId subsequent threads through 
> the synchronized block do not set queueId and the function returns null.
> Also reading from a HashMap while someone else is updating it, even with a 
> lock held, can result in a deadlock.  I have seen this happen before on 
> Hadoop.  It is likely to be very rare, but I would rather use transactional 
> memory, aka an AtomicReference, to avoid this entirely.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to