On 10/05/17 15:06, Jean-Marc Vanel wrote:
Ha OK,
alas since yesterday I restarted the app,
so pasting netsat -t result does not make sense anymore I'm afraid.
I'll post that result if calling
HttpOp.setDefaultHttpClient(HttpClients.createMinimal());
is not fixing .
Please get back either way.
I created JENA-1335 to help track this.
Andy
2017-05-10 15:52 GMT+02:00 Andy Seaborne <[email protected]>:
On 10/05/17 14:45, Jean-Marc Vanel wrote:
The OS is Ubuntu:
$ uname -a
Linux scw-80de9e 4.5.7-std-3 #1 SMP Tue Jul 12 09:56:30 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
So I ensured that this is called just once, before any HTTP requests:
HttpOp.setDefaultHttpClient(HttpClients.createMinimal());
I'll let you know if the trouble re-appears.
I understand that netstat allows me to list and kill old waiting
connections.
But I wonder whether there is a way to kill from Java such connections
after a timeout .
netstat will give us some more information as to what is happening - I'm
not suggesting it as a solution.
Andy
2017-05-10 15:06 GMT+02:00 Andy Seaborne <[email protected]>:
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$Condit
ionObject)
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(LocatorUR
L.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 ?
