Thanks for the update.
I have done a build* based on the pull request and will try it out in a
test environment, hopefully in the next few days.
I have one comment on the documentation (after a preliminary read).
Where it says
[[
The context is the merge of the server's context, any additional
settings on the dataset and any settings for the endpoint. The merge is
performed in that order - server then dataset then endpoint.
]]
Its not clear from that what sort of merge is being done. Do settings
on the server context override settings on the dataset context override
... or the other way round. I think I know what you mean - its last one
wins. Clearer might be something like
[[
The context is the merge of the server's context, any additional
settings on the dataset and any settings for the endpoint. Where
settings conflict, settings on the endpoint override settings on the
dataset and both override settings in the server context.
]]
Thanks again
Brian
* I'm not familiar with the process - did I have to do my own build - or
was their somewhere I could have pulled a ready built war file?
B
On 28/08/2019 20:45, Andy Seaborne wrote:
Code:
https://github.com/apache/jena/pull/595
Documentation draft (temp location):
https://gist.github.com/afs/1d4c6584723b72c5e7b892057029a8f4
Andy
On 06/08/2019 15:00, Brian McBride wrote:
Hi Andy,
That looks good. I'd be happy to help test it out when you get to
that point.
Brian
On 05/08/2019 17:56, Andy Seaborne wrote:
Hi Brian,
There is work-in-progress to improve configuration : JENA-1731. This
includes setting context on endpoint and dataset as well as server.
Andy
On 05/08/2019 13:57, Brian McBride wrote:
I have just had a problem with query timeout overrides when
upgrading to Fuseki 3.12.0. I think the issue is related to
JENA-1620 [1] which was deployed with Jena 3.10.0.
Essentially, JENA-1620 modified the query timeout override
functionality to constrain timeout overrides so that they must be
less than the timeout specified in the Fuseki configuration. We
have a production system that relies on being able override
timeouts with a value greater than that specified in the Fuseki
configuration file.
My question is - what is the best way for us to implement our use
case using Fuseki? We don't have to do it the way we used to do
it, but some guidance on how to approach the problem would be welcome.
We have single largish (500M triples) dataset. We expose a SPARQL
query endpoint to this data dataset to the public on the internet,
and naturally, we specify a timeout.
We also have internal applications that query the same dataset.
Their queries takes longer than the public timeout.
Prior to Fuseki 3.10.0 we could we could do this:
* two services were configured in the Fuseki config.ttl file
o a public service
o a private service
* both services shared the same dataset
o the dataset was configured with a timeout suitable for queries
from the public internet
* the private service was configured to allow query timeout override
o which we used to give our internal services more time than
specified in the configuration file
o this does not work after JENA-1620
* our proxy configuration ensured that queries from the internet can
only reach the public service
I have included a simplified version of our config.ttl file below [2].
I've been thinking about ways of achieving the desired effect
whilst respecting the change introduced by JENA-1620. An obvious
approach would be to duplicate the dataset and set different
timeouts on the different datasets. This would mean that the two
datasets were competing for memory and I would rather not do that
as it is likely to have a negative impact on performance.
I've been thinking about other approaches also, but I'll spare you
those as there might be a real simple solution I'm unaware of.
Is there a way to configure Fuseki so that different timeouts can
be set for different classes of requestor?
Brian
[1] https://issues.apache.org/jira/browse/JENA-1620
[2]
[] rdf:type fuseki:Server ;
ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue
"90000,120000" ] ;
fuseki:services (
<#service_ds>
<#service_ds_timeout_override>
) .
# TDB
[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
tdb:GraphTDB rdfs:subClassOf ja:Model .
<#service_ds> rdf:type fuseki:Service ;
rdfs:label "TDB Service" ;
fuseki:name "public" ;
fuseki:serviceQuery "query" ;
fuseki:dataset <#ds> ;
.
<#service_ds_timeout_override>
rdfs:label "TDB Service Query with
timeout override" ;
fuseki:name "private" ;
fuseki:allowTimeoutOverride true;
fuseki:serviceQuery "query" ;
fuseki:dataset <#ds> ;
.
<#ds> rdf:type tdb:DatasetTDB ;
tdb:location "/var/lib/fuseki/databases/DS" ;
tdb:unionDefaultGraph true ;
.
--
------------------------------------------------------------------------
Brian McBride
brian.mcbr...@epimorphics.com
Epimorphics Ltd www.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069
Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol
BS20 6PT, UK
