I think this relates to a HttpClient behaviour that limits the
maximum connections to a given service
At least in how Jena sets it up the default is 5 connections per
service which is more generous than the HTTP client defaults.
Jena appears to read this from a JVM property http.maxConnections
OR you can construct your own client by calling
setMaxConnPerRoute() and setMaxConnTotal() on the builder to set
your desired settings.
Rob
On 08/12/2017, 16:44, "Dave Reynolds" <dave.e.reyno...@gmail.com>
wrote:
Hi,
I've being updating some rather old libraries that use
Jena to issue
sparql requests to a remote endpoint and pull back results.
These work under Jena 3.1.1 but there's a fatal problem
under Jena 3.2.0
and later ...
If I issue 6 concurrent execSelect calls to a remote
sparql endpoint
(happens to be fuseki) then 5 will get issued and return
correctly but
#6 will not and from then onwards no further remote calls
will go
through. This only happens if at least 5 requests are in
flight with no
response yet from the remote endpoint before the final one is
issued.
It's hard to produce a deterministic, standalone test
case because by
definition it depends on an external sparql endpoint being
reliably
there and reliably not too fast :)
Looking at the stack trace I see:
Unsafe.park(boolean, long) line: not available [native
method]
LockSupport.park(Object) line: 175
AbstractQueuedSynchronizer$ConditionObject.await() line: 2039
CPool(AbstractConnPool<T,C,E>).getPoolEntryBlocking(T,
Object, long,
TimeUnit, Future<E>) line: 377
AbstractConnPool<T,C,E>.access$200(AbstractConnPool, Object,
Object,
long, TimeUnit, Future) line: 67
AbstractConnPool$2.get(long, TimeUnit) line: 243
AbstractConnPool$2.get(long, TimeUnit) line: 191
PoolingHttpClientConnectionManager.leaseConnection(Future<CPoolEntry>,
long, TimeUnit) line: 282
PoolingHttpClientConnectionManager$1.get(long, TimeUnit)
line: 269
MainClientExec.execute(HttpRoute, HttpRequestWrapper,
HttpClientContext,
HttpExecutionAware) line: 191
ProtocolExec.execute(HttpRoute, HttpRequestWrapper,
HttpClientContext,
HttpExecutionAware) line: 185
RetryExec.execute(HttpRoute, HttpRequestWrapper,
HttpClientContext,
HttpExecutionAware) line: 89
RedirectExec.execute(HttpRoute, HttpRequestWrapper,
HttpClientContext,
HttpExecutionAware) line: 111
InternalHttpClient.doExecute(HttpHost, HttpRequest,
HttpContext) line: 185
InternalHttpClient(CloseableHttpClient).execute(HttpUriRequest,
HttpContext) line: 83
InternalHttpClient(CloseableHttpClient).execute(HttpUriRequest,
HttpContext) line: 56
HttpOp.exec(String, HttpUriRequest, String, HttpResponseHandler,
HttpClient, HttpContext) line: 1081
HttpOp.execHttpGet(String, String, HttpResponseHandler,
HttpClient,
HttpContext) line: 308
HttpOp.execHttpGet(String, String, HttpClient, HttpContext)
line: 367
HttpQuery.execGet() line: 326
HttpQuery.exec() line: 288
QueryEngineHTTP.execResultSetInner() line: 348
QueryEngineHTTP.execSelect() line: 340
SSResultSet.<init>(BaseSparqlSource, String) line: 33
RemoteSparqlSource(BaseSparqlSource).streamableSelect(String)
line: 59
Which suggests some problem with the connection pool
locking.
I've tried 3.4.0 and 3.5.0 which incorporate the fix to
JENA-1335 (in
case that's related) but no luck.
I've tried both:
HttpOp.setDefaultHttpClient(HttpClients.createMinimal());
and
HttpOp.setDefaultHttpClient(HttpClients.createDefault());
right at the start of application startup.
Which don't fix the problem. Though perhaps I'm getting
the sequence of
where to set those wrong.
Any suggestions?
Any pointers to documentation on how to configure the
http client set up
in current Jena versions?
Thanks,
Dave