You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Jean-Marc Vanel <je...@gmail.com> on 2017/05/09 14:49:14 UTC
blocked threads with RDFDataMgr.loadGraph
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$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
at
org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
at
org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.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(CachingExec.java:592)
at
org.apache.http.impl.client.cache.CachingExec.handleCacheMiss(CachingExec.java:356)
at
org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.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(InternalHttpClient.java:184)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.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.openNoMapOrNull(StreamManager.java:139)
at
org.apache.jena.riot.system.stream.StreamManager.open(StreamManager.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
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org>:
>
>>
>>
>> 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 <an...@apache.org>:
>>>
>>> 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 <so...@gmail.com>:
>>>>>
>>>>> 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 ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Jean-Marc Vanel <je...@gmail.com>.
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 <an...@apache.org>:
>
>
> 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 <an...@apache.org>:
>>
>> 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 <so...@gmail.com>:
>>>>
>>>> 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
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org>:
>
>> 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 <so...@gmail.com>:
>>>
>>> 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 ?
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Jean-Marc Vanel <je...@gmail.com>.
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 .
2017-05-10 15:06 GMT+02:00 Andy Seaborne <an...@apache.org>:
> 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 <so...@gmail.com>:
>>
>> 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 ?
>>>>
>>>>
>>>>
>>
>>
--
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
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Andy Seaborne <an...@apache.org>.
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 <so...@gmail.com>:
>
>> 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 ?
>>>
>>>
>
>
Re: blocked threads with RDFDataMgr.loadGraph
Posted by Jean-Marc Vanel <je...@gmail.com>.
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 <so...@gmail.com>:
> 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 ?
>>
>>
--
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
Re: blocked threads with RDFDataMgr.loadGraph
Posted by so...@gmail.com.
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$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
> at
> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
> at
> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.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(CachingExec.java:592)
> at
> org.apache.http.impl.client.cache.CachingExec.handleCacheMiss(CachingExec.java:356)
> at
> org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.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(InternalHttpClient.java:184)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.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.openNoMapOrNull(StreamManager.java:139)
> at
> org.apache.jena.riot.system.stream.StreamManager.open(StreamManager.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 ?
>