[
https://issues.apache.org/jira/browse/TINKERPOP-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246988#comment-16246988
]
ASF GitHub Bot commented on TINKERPOP-1830:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/745
The race condition is in `put()` and it's used elsewhere. It would make
more sense to fix `put()` to be thread-safe. Then we can keep
`parallelStream()`
```
Map<Object, Set<T>> keyMap = this.index.get(key);
if (keyMap == null) {
keyMap = this.index.putIfAbsent(key, new ConcurrentHashMap<>());
}
Set<T> objects = keyMap.get(value);
if (null == objects) {
objects = keyMap.putIfAbsent(value,
ConcurrentHashMap.newKeySet());
}
objects.add(element);
```
> Race condition in Tinkergraph index creation
> ---------------------------------------------
>
> Key: TINKERPOP-1830
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1830
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
> Affects Versions: 3.3.0, 3.2.6
> Reporter: Michael Pollmeier
> Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> My colleage Fabian Yamaguchi <f...@shiftleft.io> discovered a race condition
> in tinkergraph's index creation. He fixed it by simply replacing
> `parallelStream` with `stream`. Quoting his analysis:
> > So, reading the code, you see that this.put is called in parallel, but that
> > method seems to contain a race as get is called on the index, checked for
> > null, and a subsequent write is performed. It still seems like using stream
> > here fixes the problem we've been seeing, and the performance hit is not
> > significant.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
