Hi Sebastian,
Found it - the default configuration file for TDB created by the UI has
a 3s default query timeout; it shouldn't. Sorry about that.
Workaround:
The directory run/system_files has a copy of the file. This is not the
file the server works off (that's in the database).
0/ Stop the server
1/ If you have only one dataset, copy that file to
run/configuration/mydatabase.ttl (any fresh base name, must end ttl).
2/ Edit the "run/configuration" file to remove the line:
ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "3000" ] ;
or set it to whatever you want.
3/ Delete the system database
4/ Restart the server
You can dump the system database (tdbdump; when the server is stopped)
and look to see if there is anything there. It's a regular TDB
database, albeit with custom setup to make it small (reduced caches,
block size is 1k, it's direct mode only).
I agree that keeping the persistent state in a TDB database makes its
opaque. That is something worth reconsidering. It could be all file
based which makes hacking it easier.
Andy
Record as JENA-918
On 17/04/15 19:52, Sebastian Mate wrote:
Hi Andy,
thanks for your quick reply!
No, I did not configure timeouts anywhere else. I created the TDB
datasets using the Fuseki web interface and then used tdbloader2 to
upload the triples into their respective TDB stores (with a Bash script
to make life easier).
Where else can I set this timeout option? Do I have to modify
run/config.ttl?
Just guessing - correct me if I’m wrong: It seems to me that the TDB
store itself is configured in RFD. Duh - this makes life much more
complicated! Where can I find more information about this? Is this
specific to Fuseki or TDB?
Sebastian
Am 17.04.2015 um 19:48 schrieb Andy Seaborne <[email protected]>:
Hi Sebastian,
Are timeout also set anywhere else such as the service/dataset configuration?
If so, they will override the global (server-wide) default.
The 503 message is confusing - it prints the gloabl default (100000ms) even if
the query executed under a different timeout. It looks like it it set to
3000ms somewhere else as well.
Andy
On 17/04/15 13:49, Mate, Sebastian wrote:
Dear Fuseki users,
I want to use Fuseki 2 for querying various big ontologies, e.g. dbpedia.
However, I have encountered the problem that Fuseki is ignoring the timeout
setting.
I started the server with
./fuseki-server --timeout=100000
which should set the timeout to 100s, but it is rather 3s (see below). I have
seen that there were some discussions regarding the handling of timeouts, but
I'm not sure if this is related to my problem. Here's the log - please note
that I'm using one of the latest snapshot builds (the official 2.0.0 release is
behaving the same way for me):
[2015-04-17 09:53:14] Server INFO Fuseki 2.0.1-SNAPSHOT
2015-04-16T16:45:46+0000
...
[2015-04-17 09:53:58] Config INFO Register:
/dbpedia_topical_concepts_unredirected_en
[2015-04-17 09:53:58] Config INFO Register: /dbpedia_wikipedia_links_en
[2015-04-17 09:53:58] Server INFO Started 2015/04/17 09:53:58 MESZ on port
3030
[2015-04-17 09:54:12] Fuseki INFO [1] POST
http://xxx.xxx.xxx.xxx:3030/dbpedia_page_links_unredirected_en/query
[2015-04-17 09:54:12] Fuseki INFO [1] POST
/dbpedia_page_links_unredirected_en :: 'query' ::
[application/x-www-form-urlencoded charset=UTF-8] ?
[2015-04-17 09:54:12] Fuseki INFO [1] Query = select (count(*) as ?count)
{?s ?p ?o}
[2015-04-17 09:54:15] Fuseki INFO [1] 503 The query timed out (restricted
to 100000 ms) (3,098 s)
The problem appears with other queries as well. Sometimes limiting the result set (e.g.
by appending "LIMIT 20" to the SPARQL query) helps.
The system is a quad core virtual machine with 32 GB RAM, running Ubuntu 14.04.
"java -version" is reporting:
OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-1~trusty1)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)
I would highly appreciate any advice. I really like Fuseki and would love to
use it for some data mining in medical informatics.
Many thanks,
Sebastian
------------------------------------------------------------------------------------------
Dipl.-Inf. Sebastian Mate
Lehrstuhl für Medizinische Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
Wetterkreuz 13, 91058 Erlangen-Tennenlohe, Germany
Tel. +49 (9131) 85-26722 // Fax +49 (9131) 85-26754
eMail: [email protected]
