On 31/08/2019 21:08, Brian McBride wrote:
Hi Andy,
I have tried out my build of pull request #595. I installed it on our
dev server (by replacing the fuseki-server.jar in 3.9.0 installation).
There is good news and some not so good news.
The good news is this nicely addresses the issue I raised in this email
thread. I was able to configure the timeouts settings in a way that
meets our use case and it seems to work fine.
Thank you.
There are two bits of not so good news.
1) I think the main class of the fuseki-server.jar has been renamed and
moved and so line 304 of jena-fuseki2/apache-jena-fuseki/fuseki (the
inet.d script) needs to be updated to reflect this change.
From what to what?
Are you mixing Fuseki Main (FusekiMainCmd) with Fuseki Full (FusekiCmd)
packagings / running a 3.9.0 script with your new build?
2) I ran our integration tests with the 3.13.0-SNAPSHOT installed and
got a JENA text problem. A simplifed version of the query is:
[[
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX text: <http://jena.apache.org/text#>
PREFIX ppd: <http://landregistry.data.gov.uk/def/ppi/>
PREFIX lrcommon: <http://landregistry.data.gov.uk/def/common/>
SELECT * {
?ppd_propertyAddress
text:query ( "street: the" 3000000 ) .
} LIMIT 1
]]
The fuseki log shows
[[
Cannot parse 'text:street: the ': Encountered " ":" ": "" at line 1,
column 11.
]]
This works in 3.9.0.
Our application indexes multiple properties in different fields.
I haven't had time to have a look into why this might be. Figured
someone might know of some changes in this area since 3.9.0?
Pass - but there have been significant improvement to jena-text in the
last few releases.
Andy
Best wishes
Brian
On 29/08/2019 16:16, Andy Seaborne wrote:
> * 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?
Until it is merged, that's the way to do it.
The flow is
* submit pull request
* merge
* builds (Java 8 (15mins polling), Java 11, Java 14 (once a day)) ;
* mark JIRA as "Resolved"
* development SNAPSHOT builds (Java8, nightly)
* release build for vote
* release ; Mark JIRA closed.
with discussion at any point (and after)
Andy
On 29/08/2019 15:06, Brian McBride wrote:
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 ;
.