Hello team,
we are developing a constraints checker (schema-check under Closed World
Assumption (OWL, RDFS, etc.)) for a quad store and implement it via SPARQL/HTTP.
We ran into java.net.BindException during query evaluation.
I have isolated the code and made an abstraction. So now with the following code
-----
for (int i = 0; i < 20000; i++) { // TODO (i:~16300)
QueryExecution qe =
QueryExecutionFactory.sparqlService("http://localhost:3030/Yyy/query", "select
* {?x ?y ?z}"); // only two solutions to keep the result set small
System.out.println(i);
ResultSet rs = qe.execSelect();
while (rs.hasNext()) {
System.out.println(rs.next());
}
qe.close();
}
-----
I got an exception around i > 16000 (so may be some queuing is involved) with
trace
------
HttpException: java.net.BindException: Address already in use: connect:
Unexpected error making the query: java.net.BindException: Address already in
use: connect
at com.hp.hpl.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuery.java:417)
at com.hp.hpl.jena.sparql.engine.http.HttpQuery.execGet(HttpQuery.java:358)
at com.hp.hpl.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:295)
at
com.hp.hpl.jena.sparql.engine.http.QueryEngineHTTP.execResultSetInner(QueryEngineHTTP.java:346)
at
com.hp.hpl.jena.sparql.engine.http.QueryEngineHTTP.execSelect(QueryEngineHTTP.java:338)
<own trace items>
...
Caused by: java.net.BindException: Address already in use: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
...
------
Is this a known problem? It would be nice to have some solution because I
prefer not to go back to embedded TDB, where this error probably does not occur
(?).
thanks in advance, Andreas