Phil -
Which version are you running?
Can you show the configuration file?
Andy
On 27/10/17 08:30, Dave Reynolds wrote:
On 26/10/17 12:27, Phil Gooch wrote:
Hi there
I am running Fuseki2 within Tomcat and I'm looking for a way to configure
Fuseki to limit the number of rows returned by a query. For example, to
prevent a rogue query such as
SELECT * WHERE {?s ?v ?o}
from being executed to completion.
I've imposed a maximum timeout via
ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "60000" ] ;
in config.ttl and also in the individual <dataset>.ttl files, but this
does
not seem to prevent the above query from locking up the server.
Timeouts do generally work. There used to be problems with sort queries
but those have been resolved and that's not a sort query.
Might be worth trying the two value version (time to first result and
time for whole query):
ja:context [ja:cxtName "arq:queryTimeout"; ja:cxtValue "30000,60000" ];
I've looked through the documentation at
https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
https://jena.apache.org/documentation/serving_data/#fuseki-configuration-file
https://github.com/apache/jena/tree/master/jena-fuseki2/examples
but I've not found the right config option.
Is this possible, or will I need to modify the source code to add a
LIMIT n
if this is not specified in the original query?
There's no built-in machinery to limit the number of rows so far as I
know. So if timeouts really don't work for you then indeed you would
need to inject a LIMIT clause into the queries yourself.
Timeouts are generally better because some queries are really really
hard but return few results whereas queries like the above stream
perfectly well and should impose low load, they just go on for a long time.
In our case the endpoints we expose are typically APIs where we can
inject API-specific hard/soft row limits as part of the query generation
phase. For full sparql endpoints then we rely on timeouts.
Dave
