Aklakan commented on issue #3535:
URL: https://github.com/apache/jena/issues/3535#issuecomment-3556628592
One problem I see is a locking issue:
Starting a query execution, is synchronized with abort calls. So abort -
possibly called by a timeout - has to wait for the iterator construction to
complete.
```java
- locked <0x0000000701a1c758> (a java.lang.Object)
at
org.apache.jena.sparql.exec.QueryExecDataset.execute(QueryExecDataset.java:176)
synchronized (lockTimeout) {
startQueryIteratorActual();
}
```
There is data access during the construction - and because of the prior lock
the timeout does not trigger.
I seems that the 'hasNext' operation is expensive - effectively a
`scanData.filter(false)` based on `?s text:query "totallynotfindingthisstring"`.
```java
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:122)
at
org.apache.jena.tdb2.solver.OpExecutorTDB2.optimizeExecuteQuads(OpExecutorTDB2.java:231)
if ( !input.hasNext() )
return input;
# a few lines later also
QueryIterPeek peek = QueryIterPeek.create(input, execCxt);
# followed by peek.peek()
```
Possible fixes:
* Start the timeout thread outside of the `lockTimeout` synchronized block.
It could set the cancel signal to true while the iterator is being constructed
- the QuerIterFailed introduced in my PR would exactly allow for returning a
dummy iterator for resource cleanup.
* Or: Change the logic in `optimizeExecuteQuads` to avoid eager hasNext
checks. No sure if this could be changed to lazy execution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
