On 06/05/11 10:34, Bill Roberts wrote:
Yesterday, that would have been the way to do it.
:-) Got to move quick to keep up round here. Thanks for those changes, sounds
much easier now and I'll give that a try.
Easier to write the code than to check that the query processor route
works, and has the necessary hooks. :-)
Andy
Cheers
Bill
On 6 May 2011, at 10:27, Andy Seaborne wrote:
On 05/05/11 11:06, Bill Roberts wrote:
Hi Andy
Thanks for your explanation of the current situation a couple of days
ago. I'm happy to have a go at hacking something together so that
Joseki can make use of the timeout mechanism, but would welcome some
pointers on how to get started.
Looks like I would need to adapt the existing SPARQL.java processor
in Joseki to call the setTimeout method of QueryExecution before
running the query - so in SPARQL.executeQuery, somewhere before the
call to qexec.execSelect() etc. (and if I wanted to get fancy I could
read the value out of the config file and pass it through the various
service set up classes).
What happens if the query does time out - does it return the result
set 'so far'? If no results have been found, does it return an empty
result set? Any exception to be caught and handled? Should I do
something extra in the ResponseCallback?
Thanks in advance for any advice
Bill
Yesterday, that would have been the way to do it.
But it's a bit of a burden and short term so I went into ARQ and added the
possibility of global default query timeouts. You'll still have to modify
Joseki but it now can be done in server initialization code, not needing to add
a processor.
ARQ now has:
ARQ.getContext().set(ARQ.queryTimeout, "1000")) ;
sets the timeout globally to 1 second (1000ms)). More details in the javadoc.
ARQ 2.8.9-SNAPSHOT built with that in it.
I just did a Joseki release based on ARQ 2.8.8 so now Joseki changes needing
ARQ chnages don't block a release.
Joseki POM now says 3.4.5-SNAPSHOT and depends on ARQ 2.8.9-SNAPSHOT
Andy
