It looks like the loadGraph isn't completing, isn't closing the
connection but also it looks like cases we ave seen where the OS can't
release ports in the OS fast enough, resulting in lock-ups (usually for
localhost). What happen is that after 2+ minutes, a few are released,
the app make a little progress and then stalls again.
What's the OS?
On Linux: "netstat -t" shows a lot of connections in one of the WAIT states.
Could you try with a non-caching HttpClient
one of:
HttpOp.setDefaultHttpClient(HttpClients.createMinimal());
and
HttpOp.setDefaultHttpClient(HttpClients.createDefault());
before any other code that calls out.
Andy
On 09/05/17 22:47, Jean-Marc Vanel wrote:
I just call RDFDataMgr.read(),
after setting Java timeouts to 5 and 10 seconds.
I don't know what you mean by "adjusting the default HTTP client used by
Jena" .
You mean setting global configuration on Apache HTTP client ?
I don't think so, org.apache.http appears just once:
import org.apache.http.impl.cookie.DateUtils
2017-05-09 22:41 GMT+02:00 <[email protected]>:
Looks possibly like resource contention in the HTTP machinery.
Are you adjusting the default HTTP client used by Jena?
---
A. Soroka
Jean-Marc Vanel wrote on 5/9/17 10:49 AM:
In semantic_forms, when user loads an URL, the application tries to load
RDF from it, or else it considers the URL as plain foaf:Document and
allows
the user to add triples to that URL.
So the application tries to load RDF from an URL with
RDFDataMgr.loadGraph() ( maybe there is a better way in Jena ? ).
And, sometimes, in the case of non-RDF content, blocked threads appear,
and
retrying in the web application just creates more of these identical
stacks.
Here is the top of one of the threads obtained by kill -3 :
"application-akka.actor.default-dispatcher-106" #131 prio=5 os_prio=0
tid=0x00007f0d7c01d000 nid=0x7fde waiting on condition
[0x00007f0d772f1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fef77760> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$Condit
ionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.
java:138)
at
org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(A
bstractConnPool.java:306)
at
org.apache.http.pool.AbstractConnPool.access$000(AbstractCon
nPool.java:64)
at
org.apache.http.pool.AbstractConnPool$2.getPoolEntry(
AbstractConnPool.java:192)
at
org.apache.http.pool.AbstractConnPool$2.getPoolEntry(
AbstractConnPool.java:185)
at org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager
.leaseConnection(PoolingHttpClientConnectionManager.java:276)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager
$1.get(PoolingHttpClientConnectionManager.java:263)
at
org.apache.http.impl.execchain.MainClientExec.execute(
MainClientExec.java:190)
at
org.apache.http.impl.client.cache.CachingExec.callBackend(Ca
chingExec.java:592)
at
org.apache.http.impl.client.cache.CachingExec.handleCacheMis
s(CachingExec.java:356)
at
org.apache.http.impl.client.cache.CachingExec.execute(Cachin
gExec.java:275)
at
org.apache.http.impl.execchain.ProtocolExec.execute(
ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.
java:88)
at
org.apache.http.impl.execchain.RedirectExec.execute(
RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(Int
ernalHttpClient.java:184)
at
org.apache.http.impl.client.CloseableHttpClient.execute(Clos
eableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(Clos
eableHttpClient.java:55)
at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1054)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:281)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:316)
at
org.apache.jena.riot.system.stream.LocatorHTTP.performOpen(
LocatorHTTP.java:42)
at
org.apache.jena.riot.system.stream.LocatorURL.open(LocatorURL.java:44)
at
org.apache.jena.riot.system.stream.StreamManager.openNoMapOr
Null(StreamManager.java:139)
at
org.apache.jena.riot.system.stream.StreamManager.open(Stream
Manager.java:100)
at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:829)
at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:819)
at org.apache.jena.riot.RDFDataMgr.parse(RDFDataMgr.java:664)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:212)
athttps://rolfpotts.com/lawrence-millman/
org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:105)
at org.apache.jena.riot.RDFDataMgr.loadGraph(RDFDataMgr.java:346)
That was obtained by loading https://rolfpotts.com/lawrence-millman/ , a
pure HTML page.
There are 6 of these identical stacks.
jena Version = "3.2.0" , using Play! framework 2.5.12 ( with netty-server
under the hood ).
Any idea for fixing this ?
