Some more information: When I stop the client (via Ctrl + C) the server unlocks and logs the last client request:
20:03:07 INFO Fuseki :: [253] GET http://fuseki.mooo.com:8080/dbpedia-geo/sparql?query=SELECT++*%0AWHERE%0A++%7B+%3Fs+%3Fp+%3Fo+%7D%0ALIMIT+++10%0A 20:03:07 INFO Fuseki :: [254] GET http://fuseki.mooo.com:8080/dbpedia-geo/sparql?query=SELECT++*%0AWHERE%0A++%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FSteubenville%252C_Ohio%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23lat%3E+%3Flat+.%0A++++%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FSteubenville%252C_Ohio%3E+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23long%3E+%3Flong%0A++%7D%0A After that the server answers other requests done when it was locked and it is also ready to process new requests. Regards, Regis. 2012/4/14 Regis Pires Magalhães <[email protected]> > 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 <[email protected]> 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. >>> >> >
