Aklakan commented on issue #3535:
URL: https://github.com/apache/jena/issues/3535#issuecomment-3555119941

   I opened #3603 which aims to consolidate some cancellation logic. I also 
added the non-text query as a test case (using DatasetText+TDB2 backend), but 
so far I was not able to reproduce your issue (may need to experiment with 
other dataset sizes).
   
   I have not touched `RepeatApplyIteratorPF`.
   
   Does the PR make any difference for any of your queries?
   
   For the hanging queries, can you please post the output of `jstack 
PROCESS_ID`. It produces a dump of each thread's stack trace.
   
   > `# times out after 1 second as expected, unless run after the text query 
above in which case it will run until finished.`
   
   I wonder how that happens. DatasetText only allows for a single writer - so 
a write transaction will block all readers.
   If I am not mistaken, then: Query timeouts only kick in once the query 
iterator has been built. Waiting for a (transaction) lock does not count 
towards that timeout. Read transactions should however not block each other out.
   
   Does the ignored timeout also happen when restricting the full text search 
with limits?
   Rationale: `TextIndex.query` build lists. These methods may block when 
building large lists.
   
   For example: 
https://jena.apache.org/documentation/query/text-query.html#syntax
   ```
   ?s text:query ('word' 10)                         # with limit on results
   ```
   
   Other comments:
   
   > All cancel checking is touching a volatile in some form, so we should a 
little careful about excess checking.
   
   True. I think cancel checking would be sufficient if done in the leaf 
iterator types (graphs, tables, property functions) and have cancellation 
exceptions bubble up from there. This way some checking could even be removed 
from compound iterators such as repeat apply - i.e. abort would cancel either 
lhs or rhs anyway. But that's for the future.
   
   > Your main gotcha on checking Thread.interrupted()`
   
   The main gotcha is actually that `Iterator.abort()` cannot really contain an 
interrupt to the iterator machinery.
   E.g. calling abort that interrupts on an iterator that is temporarily unused 
in another thread might incorrectly interrupt that thread.
   Iterators can respect the `Thread.interrupted()` flag and raise a 
QueryCancelledException, but the `Iterator.abort()` method must not interrupt. 
Interrupting needs to be handled on a higher level, such as Fuseki cancelling 
server threads.
   
   


-- 
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]

Reply via email to