GH-3751: Test input on entry. QueryIterFailed on all setup.#3753
GH-3751: Test input on entry. QueryIterFailed on all setup.#3753afs merged 2 commits intoapache:mainfrom
Conversation
afs
force-pushed
the
gh3751-tdb-reorder
branch
from
a32ccdf to
7a0771d
Compare
|
Overall it looks good. I occasionally got failing query cancel tests on a 14 core machine - before and with your PR. to be applied from project root with The synchronized method should solve this race-condition between regular close and concurrent cancel. An alternative might be in QueryIteratorBase to always run |
|
Meh, the patch can be further simplified by removing the nested try-catch blocks in protected QueryIterator execute(BasicPattern pattern, ReorderTransformation reorder,
QueryIterator input, ExecutionContext execCxt) {
try {
Explain.explain(pattern, execCxt.getContext()) ;
if ( reorder != null && pattern.size() >= 2 ) {
// If pattern size is 0 or 1, nothing to do.
BasicPattern bgp2 = pattern ;
// Try to ground the pattern
if ( ! input.isJoinIdentity() ) {
QueryIterPeek peek = QueryIterPeek.create(input, execCxt) ;
// And now use this one
input = peek ;
Binding b = peek.peek() ;
bgp2 = Substitute.substitute(pattern, b) ;
}
ReorderProc reorderProc = reorder.reorderIndexes(bgp2) ;
pattern = reorderProc.reorder(pattern) ;
} else {
if ( ! input.hasNext() )
return input ;
}
Explain.explain("Reorder/generic", pattern, execCxt.getContext()) ;
return PatternMatchData.execute(execCxt.getActiveGraph(), pattern, input, null, execCxt) ;
} catch (Exception e) {
return new QueryIterFailed(input, execCxt, e);
}
} |
afs
force-pushed
the
gh3751-tdb-reorder
branch
from
7a0771d to
dab66a0
Compare
|
PR revised.
What sort of machine is that? I have a Dell PC with I have seen these errors once in several months of a lot of Jena builds while removing the deprecated code and other cleaning up for Jena6. The CI on Jenkins and github has it quite often when the build systems are busy. Looks like you have found the cause of both the It's However ... 😄 ... this shows another problem.
In Rust, this code pattern would not even compile! So I think using As using I'm currently at the stage of wondering why the whole system does not crash more often! This is a common state when working on concurrency bugs. |
afs
force-pushed
the
gh3751-tdb-reorder
branch
from
dab66a0 to
45e9f50
Compare
|
My work notebook has: 12th Gen Intel(R) Core(TM) i9-12900HK (6P and 8E cores) Hm, indeed a concurrent close during
I agree. |
that word is doing a lot of work here! The exception could be an NPE. |
|
I've done about 40 builds on GH and Jenkins, 15 of them this morning (Monday) which is a typically busy time. No build failures 🎆 🥳 |
2 participants
GitHub issue resolved #3751
Hi @Aklakan - would you mind sanity checking
OpExecutorTDB2.optimizeExecuteQuads/optimizeExecuteTriplesin this PRThanks.
By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.