Hi Petr,
Thanks for the update.
Jena used Apache Apache HttpComponents Client (HttpClient) via code in
org.apache.jena.riot.web.HttpOp.
It should be using a caching ClientConnectionManager. The caching isn't
very high by default.
Or you can use your own setup HttpOp.setDefaultHttpClient.
What i think is happening is that if you don't do the close, then the
connection isn't return to the pool and a new one is created when the
next request comes in. Hence lots of connections all the way through to
the server.
Andy
On 23/12/14 20:40, Petr Baudis wrote:
On Tue, Dec 23, 2014 at 09:31:24AM +0000, Andy Seaborne wrote:
You can do it from the command line with the original tool that was
sept up into jvisualvm:
jstack ProcessId > stack_dump
(IIRC it's officially unsupported these days, but my Java 7 and 8
installations have it)
Thanks for the hint! So I saw 1024 threads with
Thread 11824: (state = IN_NATIVE)
- sun.nio.ch.FileDispatcherImpl.read0(java.io.FileDescriptor, long,
int) @bci=0 (Compiled frame; information may be imprecise)
- sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int)
@bci=4, line=39 (Compiled frame)
- sun.nio.ch.IOUtil.readIntoNativeBuffer(java.io.FileDescriptor,
java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher) @bci=114, line=223
(Compiled frame)
- sun.nio.ch.IOUtil.read(java.io.FileDescriptor, java.nio.ByteBuffer,
long, sun.nio.ch.NativeDispatcher) @bci=48, line=197 (Compiled frame)
- sun.nio.ch.SocketChannelImpl.read(java.nio.ByteBuffer) @bci=234,
line=379 (Compiled frame)
-
org.eclipse.jetty.io.nio.ChannelEndPoint.fill(org.eclipse.jetty.io.Buffer)
@bci=64, line=235 (Compiled frame)
-
org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.fill(org.eclipse.jetty.io.Buffer)
@bci=9, line=242 (Compiled frame)
- org.eclipse.jetty.http.HttpParser.fill() @bci=322, line=1044
(Compiled frame)
- org.eclipse.jetty.http.HttpParser.parseNext() @bci=177, line=298
(Compiled frame)
- org.eclipse.jetty.http.HttpParser.parseAvailable() @bci=1, line=235
(Compiled frame)
- org.eclipse.jetty.server.BlockingHttpConnection.handle() @bci=51,
line=72 (Compiled frame)
-
org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run()
@bci=129, line=298 (Compiled frame)
-
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable)
@bci=1, line=608 (Compiled frame)
- org.eclipse.jetty.util.thread.QueuedThreadPool$3.run() @bci=47,
line=543 (Compiled frame)
- java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
and 2 management threads, and the cause is pretty obvious at that point
- yes, I simply ran out of sockets! It seems Fuseki does not time out
inactive connections, but of course the true fault lies in my code which
creates so many of them - or rather never closes the connections.
That was caused by me misreading
https://jena.apache.org/documentation/query/app_api.html
and not doing qexec.close() even though I did not use the try (...) { }
construct. (It would be nice if I could reuse the same HTTP connection
for multiple *different* queries - but I don't think that's possible
here, or is it?)
Thanks,
