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