Andy, Some answers to your questions...
> and there should be a lot more results? Yes, it should return 43016 results. Did you try limiting the SERVICE calls a bit by restricting the number of > results with a LIMIT on a subquery inside a SERVICE, particualrly the first > one. Yes, if I do a limit, it works! (long term - switching to a hash join for some or all of these queries > would be better for some cases, but that's long term) Yes, it is true. If that's the end of the log, it looks as if all requests have been > responded to. (are there any "[X] GET" with no corresponding "[X] OK"?) Yes, that's the end of the log and there were 252 GETs and 252 OKs. The server is limited to the number of threads it has (5 by default but > there's no point giving it huge numbers as it'll run out of system > resources). Ok. Does nginx have any rate control configured? The execution strategy ARQ is > using is to issue a large number of hopefully quite grounded queries. I'm not using Nginx until the problem is solved. The queries are sent directly to Fuseki now (http://fuseki.mooo.com:8080/). (client side query explain might show the corresponding actions: > http://incubator.apache.org/**jena/documentation/query/**explain.html<http://incubator.apache.org/jena/documentation/query/explain.html> > ) Comparing end of log (server) and end of explain (client): end of server log: ... 19:04:03 INFO Fuseki :: [251] OK/select 19:04:03 INFO Fuseki :: [251] 200 OK 19:04:03 INFO Fuseki :: [252] GET http://fuseki.mooo.com:8080/dbpedia-geo/sparql?query=SELECT++*%0AWHERE%0A++%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FNorth_Versailles_Township%252C_Allegheny_County%252C_Pennsylvania%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23lat%3E+%3Flat+.%0A++++%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FNorth_Versailles_Township%252C_Allegheny_County%252C_Pennsylvania%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23long%3E+%3Flong%0A++%7D%0A 19:04:03 INFO Fuseki :: [252] Query = SELECT * WHERE { < http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat . < http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long } 19:04:03 INFO Fuseki :: [252] OK/select 19:04:03 INFO Fuseki :: [252] 200 OK End of client explain query using ARQ: ... 19:04:07 INFO exec :: HTTP SELECT * WHERE { < http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat . < http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long } *19:04:07 INFO exec :: HTTP* * SELECT ** * WHERE* * { <http://dbpedia.org/resource/Steubenville%2C_Ohio> < http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat .* * <http://dbpedia.org/resource/Steubenville%2C_Ohio> < http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long* * }* The client sends the "last" query, but the server was already locked and does not log that query (the red one). The server is really locked because it does not process any additional requests. Regards, Regis. On Sat, Apr 14, 2012 at 2:16 PM, Andy Seaborne <a...@apache.org> wrote: > On 13/04/12 16:29, Regis Pires Magalhăes wrote: > >> *"RC = 500 : Direct buffer memory"* only occured when Fuseki started with >> >> "exec java -Xmx1200M -jar ...". >> >> When I use *"exec java -Xmx2400M -jar ..."* even without * >> -XX:MaxDirectMemorySize* or *jetty_config.xml*, the client shows 18 >> results >> >> and stops (no exception occurs). The server gives no error. >> >> Client output: >> java -cp jena-fuseki-0.2.1-incubating-**server.jar:. Query2 >> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 >> > > and there should be a lot more results? > > Did you try limiting the SERVICE calls a bit by restricting the number of > results with a LIMIT on a subquery inside a SERVICE, particualrly the first > one. > > (long term - switching to a hash join for some or all of these queries > would be better for some cases, but that's long term) > > > Server log: >> ... >> 12:24:48 INFO Fuseki :: [251] OK/select >> 12:24:48 INFO Fuseki :: [251] 200 OK >> 12:24:48 INFO Fuseki :: [252] GET >> http://fuseki.mooo.com:8080/**dbpedia-geo/sparql?query=** >> SELECT++*%0AWHERE%0A++%7B+%**3Chttp%3A%2F%2Fdbpedia.org%** >> 2Fresource%2FNorth_Versailles_**Township%252C_Allegheny_** >> County%252C_Pennsylvania%3E+%**3Chttp%3A%2F%2Fwww.w3.org%** >> 2F2003%2F01%2Fgeo%2Fwgs84_pos%**23lat%3E+%3Flat+.%0A++++%** >> 3Chttp%3A%2F%2Fdbpedia.org%**2Fresource%2FNorth_Versailles_** >> Township%252C_Allegheny_**County%252C_Pennsylvania%3E+%** >> 3Chttp%3A%2F%2Fwww.w3.org%**2F2003%2F01%2Fgeo%2Fwgs84_pos%** >> 23long%3E+%3Flong%0A++%7D%0A<http://fuseki.mooo.com:8080/dbpedia-geo/sparql?query=SELECT++*%0AWHERE%0A++%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FNorth_Versailles_Township%252C_Allegheny_County%252C_Pennsylvania%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23lat%3E+%3Flat+.%0A++++%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FNorth_Versailles_Township%252C_Allegheny_County%252C_Pennsylvania%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23long%3E+%3Flong%0A++%7D%0A> >> 12:24:48 INFO Fuseki :: [252] Query = SELECT * WHERE {< >> http://dbpedia.org/resource/**North_Versailles_Township%2C_** >> Allegheny_County%2C_**Pennsylvania<http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> >> > >> <http://www.w3.org/2003/01/**geo/wgs84_pos#lat<http://www.w3.org/2003/01/geo/wgs84_pos#lat>> >> ?lat .< >> http://dbpedia.org/resource/**North_Versailles_Township%2C_** >> Allegheny_County%2C_**Pennsylvania<http://dbpedia.org/resource/North_Versailles_Township%2C_Allegheny_County%2C_Pennsylvania> >> > >> <http://www.w3.org/2003/01/**geo/wgs84_pos#long<http://www.w3.org/2003/01/geo/wgs84_pos#long>> >> ?long } >> 12:24:48 INFO Fuseki :: [252] OK/select >> 12:24:48 INFO Fuseki :: [252] 200 OK >> > > If that's the end of the log, it looks as if all requests have been > responded to. (are there any "[X] GET" with no corresponding "[X] OK"?) > > The server is limited to the number of threads it has (5 by default but > there's no point giving it huge numbers as it'll run out of system > resources). > > Does nginx have any rate control configured? The execution strategy ARQ > is using is to issue a large number of hopefully quite grounded queries. > > (client side query explain might show the corresponding actions: > http://incubator.apache.org/**jena/documentation/query/**explain.html<http://incubator.apache.org/jena/documentation/query/explain.html> > ) > > Andy > > >> >> >> Regards, >> Regis. >> >
