[
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/27/13 6:24 PM:
-------------------------------------------------------------
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.
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
