Hi all, > It is "graceful termination" - the query engine checks whether the > timeout has gone off, not have something interrupt a thread. > > Looking at the code, the Lucene call is returning an array of ScoreDocs > in one go so that is going to all happen. > > The rest of the query processing will terminate on timeout.
I see, thanks for the answer! There seem be some way to have a timeout in the Lucene API, but it doesn't look very straightforward... should I open a separate issue to track that? > But are you finding it is the Lucene step that is taking a long time? For some requests yes, for others it can be just a simple misspelling in a variable name that creates a query that will gratuitously go through millions of triples in a very inefficient way... > The query exits with a "QueryCancelledException" which Fuseki tries to > send back to the client. UIt can only do so if no results have been > streamed back (so works nicely for ORDER BY). > > Unfortunately, in HTTP, the response code is sent back first. So it is > possible that the client can get the 200, then some rows, then the > result stream is truncated. Fuseki writes syntactically illegal results > to force an error processing the results. This is something SPARQL 1.2 > CG may address. There are several issues that touch on this known aspect > of HTTP. Hmmm... that's an interesting problem indeed... good idea to have the CG address that! What does the Jena code (in the client) do when it receives such a malformed result? Is there any chance the exception can be spotted and returned? Best, -- Elie
