[
https://issues.apache.org/jira/browse/TINKERPOP-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247717#comment-16247717
]
ASF GitHub Bot commented on TINKERPOP-1830:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/745
@mpollmeier Sorry, I thought that `putIfAbsent()` returned the current map
but it returns old mapping or `null` hence the `NPEs`. Should be:
```java
protected void put(final String key, final Object value, final T
element) {
Map<Object, Set<T>> keyMap = this.index.get(key);
if (null == keyMap) {
Map<Object, Set<T>> tmpMap = new ConcurrentHashMap<>();
this.index.putIfAbsent(key, tmpMap);
keyMap = this.index.get(key);
}
Set<T> objects = keyMap.get(value);
if (null == objects) {
Set<T> tmpObjects = ConcurrentHashMap.newKeySet();
keyMap.putIfAbsent(value, tmpObjects);
objects = keyMap.get(value);
}
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)
