Once the caller has a TupleQueryResult (or GraphQueryResult) object, invoking.close() on that object should do a IRunningQuery.cancel(true/mayInterruptIfRunning/).
This ticket is a task request to verify the correct functioning of this feature.
Correct interruption of some query plans is heavily tested by BSBM queries that use a LIMIT. When the LIMIT is reached, the SliceOp internally causes the query to be cancelled.
However, we need to either (a) audit the BSBM query plans to verify that this works for nested query plans or (b) develop new tests that look for a failure to cancel a sub-select or other interesting query structures in a timely fashion.
Note: The query deadline is a completely different mechanism. The query timeout is expressed in seconds through the openrdf AP (AbstractQuery.setMaxQueryTime(int:seconds). The maxQueryTime is translated into a milliseconds timeout by BigdataSailTupleQuery.evaluate() and friends and then converted into a deadline within the RunState of the AbstractRunningQuery. The RunState only examines the deadline when bigdata operators start/stop. If a query has a bad plan, then it might spam the heap and cause big GC pauses that do not allow it to make progress. In this case, it might not halt at the deadline because bops do not start/stop. Other problems that could result in a missed deadline would be an operator that builds a very large hash index from an unconstrained index scan, etc.