Returning a copy collection to avoid corrupted iterator
In a highly concurrent environment, within a single JanusGraph transaction, where multiple thousands of vertices are being created, I have been observing an exception:
throwable.cause.class="java.lang.IllegalArgumentException",throwable.cause.msg="expected one element but was: <Artifact, Artifact>",throwable.cause.stack="
at com.google.common.collect.Iterators.getOnlyElement(Iterators.java:315)
at com.google.common.collect.Iterators.getOnlyElement(Iterators.java:327)
at com.google.common.collect.Iterables.getOnlyElement(Iterables.java:268)
at org.janusgraph.graphdb.vertices.AbstractVertex.getVertexLabelInternal(AbstractVertex.java:126)
at org.janusgraph.graphdb.vertices.AbstractVertex.vertexLabel(AbstractVertex.java:135)
at org.janusgraph.graphdb.vertices.AbstractVertex.label(AbstractVertex.java:121)
at org.janusgraph.graphdb.types.system.ImplicitKey.computeProperty(ImplicitKey.java:83)
at org.janusgraph.graphdb.query.vertex.BasicVertexCentricQueryBuilder.executeImplicitKeyQuery(BasicVertexCentricQueryBuilder.java:211)
at org.janusgraph.graphdb.query.vertex.VertexCentricQueryBuilder.properties(VertexCentricQueryBuilder.java:99)
at org.janusgraph.graphdb.util.ElementHelper.getValues(ElementHelper.java:41)
at org.janusgraph.graphdb.query.condition.PredicateCondition.evaluate(PredicateCondition.java:68)
at org.janusgraph.graphdb.query.condition.And.evaluate(And.java:55)
at org.janusgraph.graphdb.query.graph.GraphCentricQuery.matches(GraphCentricQuery.java:153)
at com.google.common.collect.Iterators$5.computeNext(Iterators.java:637)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
at org.janusgraph.graphdb.query.QueryProcessor.getUnfoldedIterator(QueryProcessor.java:98)
at org.janusgraph.graphdb.query.QueryProcessor.iterator(QueryProcessor.java:67)
at org.janusgraph.graphdb.query.graph.GraphCentricQueryBuilder$1.iterator(GraphCentricQueryBuilder.java:204)
at org.janusgraph.graphdb.query.graph.GraphCentricQueryBuilder$1.iterator(GraphCentricQueryBuilder.java:201)
at org.janusgraph.graphdb.tinkerpop.optimize.JanusGraphStep.executeGraphCentricQuery(JanusGraphStep.java:160)
at org.janusgraph.graphdb.tinkerpop.optimize.JanusGraphStep.lambda$new$1(JanusGraphStep.java:95)
at java.lang.Iterable.forEach(Iterable.java:75)
at org.janusgraph.graphdb.tinkerpop.optimize.JanusGraphStep.lambda$new$2(JanusGraphStep.java:95)
at org.apache.tinkerpop.gremlin.process.traversal.step.map.GraphStep.processNextStart(GraphStep.java:157)
at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
After an investigation, I have found that the container of vertex relationships might be modified and iterated in parallel, causing a corrupted iterator.
To solve an issue, I have made the function to return a copy of the current iterator state.
The committers listed above are authorized under a signed CLA.
- :white_check_mark: login: ntisseyre / name: Natalia Tisseyre (0feb9536f926a1ab282001043bbeb45d2d229a07)
Please verify the committer name, email, and GitHub username association are all correct and match CLA records.
Hey @ntisseyre ! Happy to see you here 😄
I added some comments regarding this PR, because I don't know the purpose of the changes. I assume they might be needed for latter contributions.
Besides that, you will need to sign either ICLA or CCLA, so that we could merge that work into JanusGraph. You can check the contribution guide here: https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTING.md#sign-the-cla
Also, each commit has to be signed by you. You can update your commit signature via
git commit --amend -s. See instructions about signing commits here: https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTING.md#commit-changes-and-sign-the-developer-certificate-of-originPlease, let me know if you need any help there and I can jump in.
Thank you! I'm working on my CLA
@JanusGraph/committers I will be merging this PR in a week following lazy consensus unless anyone else jumps in for the review.
Merging by following lazy consensus. Backporting to 1.0.
💚 All backports created successfully
| Status | Branch | Result |
|---|---|---|
| ✅ | v1.0 |
Note: Successful backport PRs will be merged automatically after passing CI.
Questions ?
Please refer to the Backport tool documentation and see the Github Action logs for details