[
https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721708#comment-13721708
]
Andy Seaborne edited comment on JENA-218 at 7/28/13 2:38 PM:
-------------------------------------------------------------
This is looking good. I like the proposed configuration file details.
I'm not worried about not setting the two timeouts separately; in fact, I'm not
sure it's a good idea at all because it is complicated to have something set in
two places - easy to make mistakes.
*ARQ.queryTimeout*
We can keep compatibility by setting via this first, then proceeding with the
defined {{fuseki:}} settings. We can't stop {{ARQ.queryTimeout}} because there
are are other ways to set it.
We can have an ordered hierarchy of setting:
Any {ARQ.queryTimeout} -- Global (cmd line settings) -- Server -- Service
which if set in that order, means the more specific one wins.
*Command line*
One issue is the commandline {{\-\-timeout X}} or {{\-\-timeout X,Y}} which is
setting ARQ.queryTimeout (in ms).
We could simple deprecate and replace with {{\-\-defaultTimeout}} and
{{\-\-maximumTimeoutOverride}} but the command line is more about easy setup,
usually without config file. I see {{\-\-timeout X}} as being the important
case; put in some sort of timeout to guard aginst errant queries.
Seconds are a better choice. Adding units (e.g. "20ms") seems excessive for
fuseki and can be done with fractional settings. The ARQ API uses millis by
default because it is common in APIs however network use and very fine grained
timeouts don't make a lot of sense.
We could take over {{\-\-timeout}} as the initial setting (and the config file
overrides) of both {{fuseki:defaultTimeout}} and
{{fuseki:maximumTimeoutOverride}}, and migrate to seconds by assuming (with
warning) X000 is ms. So if you want to do simple things, the command line is
enough but complicated mixes of {{defaultTimeout}} and
{{maximumTimeoutOverride}} need to be done with a configuration file.
was (Author: andy.seaborne):
This is looking good. I like the proposed configuration file details.
I'm not worried about setting the two timeouts separately; in fact, I'm not
sure it's a good idea at all because it is complicated to have something set in
two places - easy to make mistakes.
*ARQ.queryTimeout*
We can keep compatibility by setting via this first, then proceeding with the
defined {{fuseki:}} settings. We can't stop {{ARQ.queryTimeout}} because there
are are other ways to set it.
We can have an ordered hierarchy of setting:
Global(any ARQ.queryTimeout) -- Server -- Service
which if set in that order, means the more specific one wins.
*Command line*
One issue is the commandline {{\-\-timeout X}} or {{\-\-timeout X,Y}} which is
setting ARQ.queryTimeout (in ms).
We could simple deprecate and replace with {{\-\-defaultTimeout}} and
{{\-\-maximumTimeoutOverride}} but the command line is more about easy setup,
usually without config file.
Seconds are a better choice. Adding units (e.g. "20ms") seems excessive.
We could take over {{\-\-timeout}} as the initial setting (and the config file
overrides) of both {{fuseki:defaultTimeout}} and
{{fuseki:maximumTimeoutOverride}}, and migrate to seconds by assuming (with
warning) X000 is ms. So if you want to do simple things, the command line is
enough but complicates mixes of {{defaultTimeout}} and
{{maximumTimeoutOverride}} need to be done with a configuration file.
*Other*
As well as integers, we could allow the property values to be any numbers,
specifically decimals. 100ms is then a setting of 0.1.
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
> Key: JENA-218
> URL: https://issues.apache.org/jira/browse/JENA-218
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
> Affects Versions: Fuseki 0.2.1
> Reporter: Alexander Dutton
> Assignee: Andy Seaborne
> Labels: needsdocumentation, timeout
> Attachments: config-tdb.ttl, jena-218-1.diff,
> jena-218-default-timeout.diff
>
>
> A query endpoint might want to have different timeouts depending on whether
> queries are from untrusted or trusted users, or maintenance processes. The
> timeout could be passed with an X- header, a Timeout header as per
> http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query
> parameter, respecting the system default if none is provided. The query
> parameter might be less favourable as it'd be harder to filter out for Fuseki
> instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be
> overridden will lead to DoSs of query endpoints open to the world to some
> extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at
> http://incubator.apache.org/jena/documentation/serving_data/.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
