On 26/10/17 12:27, Phil Gooch wrote:
Hi thereI 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
