afs commented on issue #3755:
URL: https://github.com/apache/jena/issues/3755#issuecomment-3905146269
> All iterators involved in query execution should ideally be abortable
the work of the abort wil be on the query execution thread (which maybe
inside a transaction, and the signal is from outside). For `QueryIterAbortable`
it can be part of `close`.
`QueryIterPlainWrapperCloseOnAbort` is what `QueryIterAbortable` is trying
to be for clear-up, not interrupt, style abort.
The query execution thread has to throw `QueryCancelledException` so that it
works it way up through the transaction mechanism and to the `QueryExec`.
It is possible there are, or will be operations, that are in middle of
something when the cancel signal is set and need to be poked c.f. thread
interrupt.
I can't think of any in the ARQ/DBOE/TDB code. Are there any in the service
enhancer?
Otherwise, it's a similar situation (not quite as serious as it isn't
potentially VM or retaining locks) to `Thread.stop`.
Using the execution context cancel:
```java
@Override
protected boolean hasNextBinding() {
possibleCancellation();
return iterator.hasNext();
}
private void possibleCancellation() {
ExecutionContext execCxt = super.getExecContext();
if ( execCxt == null )
return;
AtomicBoolean cancelSignal = execCxt.getCancelSignal();
if ( cancelSignal != null && cancelSignal.get() ) {
closeIterator();
throw new QueryCancelledException();
}
}
```
(`AtomicBoolean` may be stronger then needed).
--
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]
