You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Firmstone (JIRA)" <ji...@apache.org> on 2015/12/04 13:22:10 UTC

[jira] [Updated] (RIVER-348) Possible race condition in net.jini.lookup.ServiceDiscoveryManager addProxyReg

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

Peter Firmstone updated RIVER-348:
----------------------------------
    Affects Version/s: River_2.1.1
                       River_2.1.2
                       River_2.2.0
                       River_2.2.1
                       River_2.2.2

> Possible race condition in net.jini.lookup.ServiceDiscoveryManager addProxyReg
> ------------------------------------------------------------------------------
>
>                 Key: RIVER-348
>                 URL: https://issues.apache.org/jira/browse/RIVER-348
>             Project: River
>          Issue Type: Bug
>    Affects Versions: River_2.1.1, River_2.1.2, River_2.2.0, River_2.2.1, River_2.2.2
>            Reporter: Patricia Shanahan
>            Priority: Minor
>             Fix For: River_3.0.0
>
>         Attachments: qaresult-servicediscovery-JC-20100829.zip
>
>
> SDM appears to assume that tasks with sequence numbers are added to their TaskManager in ascending sequence number order. The method addProxyReg increments the sequence number in a serviceIdMap synchronized block, but does not add the task to its TaskManager until outside the block. leaving a small window during which another task could be created with higher sequence number but added to the TaskManager first.
> There is no known test case reproducing this, so it is difficult to be sure there is nothing else preventing the problem from happening.
> The fix wold be to move the cacheTaskMgr.add(treg); call inside the synchronized block.



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