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 .
