On 31/08/2019 21:51, Andy Seaborne wrote:
[...]
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?
Yes. I dropped the newly built fuseki-server.jar into the directory
installed from 3.9.0 (untar of fuseki-...tar.gz).
I then modified the init.d script to use FusekiMainCmd rather than
FusekiCmd and it started up ok and seemed to work which seemed fine for
my test.
I checked the version of the init.d script in the source GIT tree and
saw that it still used FusekiCmd so wondered if maybe the class had been
renamed/moved but the init script was not updated to match. This will
only be a problem in the relatively rare cases where some extra jars are
configured on the Fuseki class path - normal startup just runs the jar
rather than specifying the main class in the command line - so
conceivably might not get caught by routine testing.
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:
[...]
Pass - but there have been significant improvement to jena-text in the
last few releases.
Good to know. I *think* that the text query that is causing a problem in
3.13.0-SNAPSHOT worked in 3.12.0. But I would need to confirm to be sure.
Brian
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 ;
.
--
------------------------------------------------------------------------
Brian McBride
[email protected]
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
