[
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)