You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/05/02 14:51:35 UTC
Re: Error in Federated Query
Hi there,
Sorry for the delay.
I've managed to turn this into a test case.
Using ARQ and fuseki from development (recent snapshot builds will do
the same), and daft data + query, I can get it reliably to lock up at 50
triples; 40 does not reliably.
The query is a cross product of the database - the execution plan is
going to be 2500 calls in the second SERVICE.
I tried:
1/ putting in a short delay after the execution of service and it works.
The delay was 5ms - not even an OS timeslice. I guess this causes the
OS to switch processes or otherwise be able to clear up resources. 1ms
didn't work. 2ms did -- I only tried a coupel of times though.
2/ Setting the connection to be closed after use always
(i.e. HTTP header "Connection: close")
Tentative conclusion: it's the server/OS not being able to sort out
connections fast enough. ARQ, or the Java runtime, isn't recycling
connections which maybe because the URL changes everytime but probbaly
because I don't understand how connection caching is supposed to work in
Java when naively use java.net.
Not sure of the best solution at the moment.
Andy
---- Query ----
PREFIX : <http://example/>
SELECT (count(*) AS ?c)
FROM <file:D.nt>
{
SERVICE <http://localhost:3030/ds/query> { ?s ?p ?o . ?s1 ?p1 ?o1 }
SERVICE <http://localhost:3030/ds/query> { ?s1 ?p1 ?o1 }
}
---- Query ----
data:
fuseki --file=D.ttl /ds
---- Data
# 50 triples
@prefix : <http://example/> .
:x :p 1 .
:x :p 2 .
:x :p 3 .
:x :p 4 .
:x :p 5 .
:x :p 6 .
:x :p 7 .
:x :p 8 .
:x :p 9 .
:x :p 10 .
:x :p 11 .
:x :p 12 .
:x :p 13 .
:x :p 14 .
:x :p 15 .
:x :p 16 .
:x :p 17 .
:x :p 18 .
:x :p 19 .
:x :p 20 .
:x :p 21 .
:x :p 22 .
:x :p 23 .
:x :p 24 .
:x :p 25 .
:x :p 26 .
:x :p 27 .
:x :p 28 .
:x :p 29 .
:x :p 30 .
:x :p 31 .
:x :p 32 .
:x :p 33 .
:x :p 34 .
:x :p 35 .
:x :p 36 .
:x :p 37 .
:x :p 38 .
:x :p 39 .
:x :p 40 .
:x :p 41 .
:x :p 42 .
:x :p 43 .
:x :p 44 .
:x :p 45 .
:x :p 46 .
:x :p 47 .
:x :p 48 .
:x :p 49 .
:x :p 50 .
Re: Error in Federated Query
Posted by Regis Pires Magalhães <re...@gmail.com>.
Andy,
I suppose the problem is in the server side (Fuseki) and not in the client
side (ARQ).
I say this because now I have the same data in Fuseki (Jena TDB) and
Virtuoso.
Both are installed in the same host.
I get all the results from Virtuoso, but not from Fuseki using the same
client application and query.
Regards,
Regis.
On Wed, May 2, 2012 at 9:51 AM, Andy Seaborne <an...@apache.org> wrote:
> Hi there,
>
> Sorry for the delay.
>
> I've managed to turn this into a test case.
>
> Using ARQ and fuseki from development (recent snapshot builds will do the
> same), and daft data + query, I can get it reliably to lock up at 50
> triples; 40 does not reliably.
>
> The query is a cross product of the database - the execution plan is going
> to be 2500 calls in the second SERVICE.
>
> I tried:
>
> 1/ putting in a short delay after the execution of service and it works.
> The delay was 5ms - not even an OS timeslice. I guess this causes the OS
> to switch processes or otherwise be able to clear up resources. 1ms
> didn't work. 2ms did -- I only tried a coupel of times though.
>
> 2/ Setting the connection to be closed after use always
> (i.e. HTTP header "Connection: close")
>
> Tentative conclusion: it's the server/OS not being able to sort out
> connections fast enough. ARQ, or the Java runtime, isn't recycling
> connections which maybe because the URL changes everytime but probbaly
> because I don't understand how connection caching is supposed to work in
> Java when naively use java.net.
>
> Not sure of the best solution at the moment.
>
> Andy
>
> ---- Query ----
> PREFIX : <http://example/>
>
> SELECT (count(*) AS ?c)
> FROM <file:D.nt>
> {
> SERVICE <http://localhost:3030/ds/**query<http://localhost:3030/ds/query>>
> { ?s ?p ?o . ?s1 ?p1 ?o1 }
> SERVICE <http://localhost:3030/ds/**query<http://localhost:3030/ds/query>>
> { ?s1 ?p1 ?o1 }
> }
> ---- Query ----
>
> data:
> fuseki --file=D.ttl /ds
>
> ---- Data
> # 50 triples
> @prefix : <http://example/> .
>
> :x :p 1 .
> :x :p 2 .
> :x :p 3 .
> :x :p 4 .
> :x :p 5 .
> :x :p 6 .
> :x :p 7 .
> :x :p 8 .
> :x :p 9 .
> :x :p 10 .
> :x :p 11 .
> :x :p 12 .
> :x :p 13 .
> :x :p 14 .
> :x :p 15 .
> :x :p 16 .
> :x :p 17 .
> :x :p 18 .
> :x :p 19 .
> :x :p 20 .
> :x :p 21 .
> :x :p 22 .
> :x :p 23 .
> :x :p 24 .
> :x :p 25 .
> :x :p 26 .
> :x :p 27 .
> :x :p 28 .
> :x :p 29 .
> :x :p 30 .
>
> :x :p 31 .
> :x :p 32 .
> :x :p 33 .
> :x :p 34 .
> :x :p 35 .
> :x :p 36 .
> :x :p 37 .
> :x :p 38 .
> :x :p 39 .
> :x :p 40 .
>
> :x :p 41 .
> :x :p 42 .
> :x :p 43 .
> :x :p 44 .
> :x :p 45 .
> :x :p 46 .
> :x :p 47 .
> :x :p 48 .
> :x :p 49 .
> :x :p 50 .
>