You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Adrian Gschwend <ml...@netlabs.org> on 2015/08/23 17:23:51 UTC

Re: Fuseki 2.0 configuration issues

On 09.07.15 11:03, Andy Seaborne wrote:

Hi Andy,


>>> Could this be JENA-918?
>>>
>>>      Andy
>>>
>>> https://issues.apache.org/jira/browse/JENA-918
>>
>> oh I didn't see there is a tdb-config as well. I just changed it there
>> to 5000ms and I still get the error.
>>
>> Can I somehow see what is set at runtime?
> 
> Not really though it would a good idea to annotate the log at the start
> of the query with the timeout set.

that would definitely help for debugging. I can't see that in 2.3.0
release, right?

> The snapshot development version is 2.3.0-SNAPHOT
> 
> If you could try that, it would be very helpful.
> 
> The "3 second" timeout is the marker for JENA-918 but if every setting
> is different to 3000 then I can't explain the situation.  If you could
> send me all the configuration files you use, I will try to recreate this
> when I'm back online (I'm "away" this week)

I still have that on 2.3.0. Do you want just the configuration or also
the data which triggers it? It's gonna be open data so it's not a problem.

Would it be enough to tar the "run" directory or is this not portable?

regards

Adrian

Re: Fuseki 2.0 configuration issues

Posted by Andy Seaborne <an...@apache.org>.
On 29/08/15 15:39, Adrian Gschwend wrote:
> On 25.08.15 14:06, Andy Seaborne wrote:
>
> Hi Andy,
>
>> The problem is that the configuration of the "bfs" dataset is picked up
>> from the configuration database.  Presumably you created it through the UI.
>
> I did! Thanks a lot for the hint. Is this somewhere written in the
> documentation? I know that I am not the only one who was running into
> that, I've seen similar questions outside the mailinglist.

Putting it in the system database didn't turn out a good idea hence the 
change at 2.3.0 (I can see now Fuseki would have to add editing 
configuration file capabilities which would be nice but is distinctly 
non-trivial).

What I still don't completely understand is why some people come across 
this and not others.  Makes writing useful document tricky!

	Andy

>> That has an assembler that has a timeout of 3000ms for that dataset.
>>
>> In Fuseki v2.3.0, UI created databases don't go into the system database
>> any more - they go into run/configuration/ as turtle so they are easier
>> to edit.
>>
>> You can either edit, with SPARQL Update, the system database or,
>> simpler, delete the system database entirely (it only had one assembler
>> in it) and put a file in run/configuration/.
>>
>> There is one for bfs below I used in testing, with your database
>> location in it.. It also has all the unnecessary initialization stuff
>> removed that is no longer needed for Fuseki 2.3 + TDB. After all, Fuseki
>> itself uses TDB so TDB setup and writing for assemblers happens anyway.
>
> great tnx, will work with this one!
>
> regards
>
> Adrian
>


Re: Fuseki 2.0 configuration issues

Posted by Adrian Gschwend <ml...@netlabs.org>.
On 25.08.15 14:06, Andy Seaborne wrote:

Hi Andy,

> The problem is that the configuration of the "bfs" dataset is picked up
> from the configuration database.  Presumably you created it through the UI.

I did! Thanks a lot for the hint. Is this somewhere written in the
documentation? I know that I am not the only one who was running into
that, I've seen similar questions outside the mailinglist.

> That has an assembler that has a timeout of 3000ms for that dataset.
> 
> In Fuseki v2.3.0, UI created databases don't go into the system database
> any more - they go into run/configuration/ as turtle so they are easier
> to edit.
> 
> You can either edit, with SPARQL Update, the system database or,
> simpler, delete the system database entirely (it only had one assembler
> in it) and put a file in run/configuration/.
> 
> There is one for bfs below I used in testing, with your database
> location in it.. It also has all the unnecessary initialization stuff
> removed that is no longer needed for Fuseki 2.3 + TDB. After all, Fuseki
> itself uses TDB so TDB setup and writing for assemblers happens anyway.

great tnx, will work with this one!

regards

Adrian

Re: Fuseki 2.0 configuration issues

Posted by Andy Seaborne <an...@apache.org>.
Hi Adrian,

The problem is that the configuration of the "bfs" dataset is picked up 
from the configuration database.  Presumably you created it through the UI.

That has an assembler that has a timeout of 3000ms for that dataset.

In Fuseki v2.3.0, UI created databases don't go into the system database 
any more - they go into run/configuration/ as turtle so they are easier 
to edit.

You can either edit, with SPARQL Update, the system database or, 
simpler, delete the system database entirely (it only had one assembler 
in it) and put a file in run/configuration/.

There is one for bfs below I used in testing, with your database 
location in it.. It also has all the unnecessary initialization stuff 
removed that is no longer needed for Fuseki 2.3 + TDB. After all, Fuseki 
itself uses TDB so TDB setup and writing for assemblers happens anyway.

	Andy

---- configuration/bfs.ttl -----------------------
@prefix :      <http://base/#> .
@prefix tdb:   <http://jena.hpl.hp.com/2008/tdb#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ja:    <http://jena.hpl.hp.com/2005/11/Assembler#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix fuseki: <http://jena.apache.org/fuseki#> .

:service_tdb_all  rdf:type            fuseki:Service ;
     rdfs:label                        "TDB bfs" ;
     fuseki:name                       "bfs" ;
     fuseki:serviceQuery               "query" ;
     fuseki:serviceQuery               "sparql" ;
     fuseki:serviceReadGraphStore      "get" ;
     fuseki:serviceReadWriteGraphStore "data" ;
     fuseki:serviceUpdate              "update" ;
     fuseki:serviceUpload              "upload" ;
     fuseki:dataset                    :tdb_dataset_readwrite
     .

:tdb_dataset_readwrite rdf:type       tdb:DatasetTDB ;
     tdb:location
         "/Users/ktk/workspace/zazuko.bfs/fuseki/run/databases/bfs" ;
     ja:context [ ja:cxtName "arq:queryTimeout" ;  ja:cxtValue "1000" ] ;
     .







On 25/08/15 08:31, Andy Seaborne wrote:
> Hi Adrian,
>
> I've downloaded the file successfully and wil look at the issue as soon
> as I can.
>
>      Andy
>
> On 24/08/15 18:55, Adrian Gschwend wrote:
>> On 24.08.15 13:05, Andy Seaborne wrote:
>>
>> Hi Andy,
>>
>>> Adrian - That would be perfect.  I don't think I need the data, just
>>> the setup.  It would also be useful to know exactly how you are
>>> making the call.  A per-query timeout is possible with the header
>>> "Timeout:" or parameter &timeout=.
>>
>> I use this curl command to execute it:
>>
>> curl -H "Accept: application/n-triples" --data-urlencode
>> query@construct/map_municipality2classes.sparql
>> http://localhost:3030/bfs/sparql -o out/map_municipality2classes.nt
>>
>> Didn't check the exact header sent though.
>
> It'll be OK - curl does not add anything relevant.
>
>> I've tared everything including the data, it's just 14MB compressed.
>> Execute fuseki-server within the "fuseki" subdirectory, the shell-script
>> fuseki-construct.sh fires a bunch of construct queries into "out"
>> directory.
>>
>> http://ktk.netlabs.org/misc/fuseki-timeout.tar.bz2
>>
>> Note that the one I mention above is commented-out right now in this
>> shell script.
>>
>> regards
>>
>> Adrian
>>
>


Re: Fuseki 2.0 configuration issues

Posted by Andy Seaborne <an...@apache.org>.
Hi Adrian,

I've downloaded the file successfully and wil look at the issue as soon 
as I can.

	Andy

On 24/08/15 18:55, Adrian Gschwend wrote:
> On 24.08.15 13:05, Andy Seaborne wrote:
>
> Hi Andy,
>
>> Adrian - That would be perfect.  I don't think I need the data, just
>> the setup.  It would also be useful to know exactly how you are
>> making the call.  A per-query timeout is possible with the header
>> "Timeout:" or parameter &timeout=.
>
> I use this curl command to execute it:
>
> curl -H "Accept: application/n-triples" --data-urlencode
> query@construct/map_municipality2classes.sparql
> http://localhost:3030/bfs/sparql -o out/map_municipality2classes.nt
>
> Didn't check the exact header sent though.

It'll be OK - curl does not add anything relevant.

> I've tared everything including the data, it's just 14MB compressed.
> Execute fuseki-server within the "fuseki" subdirectory, the shell-script
> fuseki-construct.sh fires a bunch of construct queries into "out" directory.
>
> http://ktk.netlabs.org/misc/fuseki-timeout.tar.bz2
>
> Note that the one I mention above is commented-out right now in this
> shell script.
>
> regards
>
> Adrian
>


Re: Fuseki 2.0 configuration issues

Posted by Adrian Gschwend <ml...@netlabs.org>.
On 24.08.15 13:05, Andy Seaborne wrote:

Hi Andy,

> Adrian - That would be perfect.  I don't think I need the data, just
> the setup.  It would also be useful to know exactly how you are
> making the call.  A per-query timeout is possible with the header
> "Timeout:" or parameter &timeout=.

I use this curl command to execute it:

curl -H "Accept: application/n-triples" --data-urlencode
query@construct/map_municipality2classes.sparql
http://localhost:3030/bfs/sparql -o out/map_municipality2classes.nt

Didn't check the exact header sent though.

I've tared everything including the data, it's just 14MB compressed.
Execute fuseki-server within the "fuseki" subdirectory, the shell-script
fuseki-construct.sh fires a bunch of construct queries into "out" directory.

http://ktk.netlabs.org/misc/fuseki-timeout.tar.bz2

Note that the one I mention above is commented-out right now in this
shell script.

regards

Adrian

Re: Fuseki 2.0 configuration issues

Posted by Andy Seaborne <an...@apache.org>.
On 23/08/15 16:23, Adrian Gschwend wrote:
> On 09.07.15 11:03, Andy Seaborne wrote:
>
> Hi Andy,
>
>
>>>> Could this be JENA-918?
>>>>
>>>>       Andy
>>>>
>>>> https://issues.apache.org/jira/browse/JENA-918
>>>
>>> oh I didn't see there is a tdb-config as well. I just changed it there
>>> to 5000ms and I still get the error.
>>>
>>> Can I somehow see what is set at runtime?
>>
>> Not really though it would a good idea to annotate the log at the start
>> of the query with the timeout set.
>
> that would definitely help for debugging. I can't see that in 2.3.0
> release, right?

Right.

>
>> The snapshot development version is 2.3.0-SNAPHOT
>>
>> If you could try that, it would be very helpful.
>>
>> The "3 second" timeout is the marker for JENA-918 but if every setting
>> is different to 3000 then I can't explain the situation.  If you could
>> send me all the configuration files you use, I will try to recreate this
>> when I'm back online (I'm "away" this week)
>
> I still have that on 2.3.0. Do you want just the configuration or also
> the data which triggers it? It's gonna be open data so it's not a problem.
>
> Would it be enough to tar the "run" directory or is this not portable?

Adrian - That would be perfect.  I don't think I need the data, just the 
setup.  It would also be useful to know exactly how you are making the 
call.  A per-query timeout is possible with the header "Timeout:" or 
parameter &timeout=.

	Andy

>
> regards
>
> Adrian
>