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 .
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 ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
--
Jean-Marc Vanel
http://www.semantic-forms.cc:9111/display?displayuri=http://jmvanel.free.fr/jmv.rdf%23me
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
+33 (0)6 89 16 29 52
Twitter: @jmvanel , @jmvanel_fr ; chat: irc://irc.freenode.net#eulergui
