hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Greene (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPASYNC-29) Orphan I/O dispatcher threads
Date Sun, 07 Oct 2012 22:40:03 GMT

    [ https://issues.apache.org/jira/browse/HTTPASYNC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471349#comment-13471349
] 

Mark Greene commented on HTTPASYNC-29:
--------------------------------------

Hi Oleg,

Thank you for your prompt response.

Looking at my application code, it would technically be possible for a client to be started
but not shutdown given it was created outside the try/finally block where the finally block
shuts the client down. I will change that to make 100% sure this case can't happen. I did
however, go back in the logs and see if any exceptions arose in the potential areas and I
did not see any so I'm somewhat sure this case didn't happen. 

Give me ~48 hours to deploy this fix to my production environment and get back to you via
this issue. 
                
> Orphan I/O dispatcher threads 
> ------------------------------
>
>                 Key: HTTPASYNC-29
>                 URL: https://issues.apache.org/jira/browse/HTTPASYNC-29
>             Project: HttpComponents HttpAsyncClient
>          Issue Type: Bug
>    Affects Versions: 4.0-beta2, 4.0-beta3
>         Environment: CentOS 5
>            Reporter: Mark Greene
>
> I'm seeing a very slow thread leak in my application resulting from the async http client.
It takes several days for these threads to amount to anything significant (e.g. 100-300).

> Here is an example of the stack traces of the thread dump:
> "I/O dispatcher 6138" daemon prio=10 tid=0x09644000 nid=0x1137 runnable [0xf2071000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> 	- locked <0xa519af78> (a sun.nio.ch.Util$2)
> 	- locked <0xa519af88> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xa519af38> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> 	at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:259)
> 	at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:106)
> 	at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:604)
> 	at java.lang.Thread.run(Thread.java:662)
> and this one as well:
> "Thread-4612" daemon prio=10 tid=0xf2e11400 nid=0x1b62 runnable [0xf2340000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> 	- locked <0xa519dc10> (a sun.nio.ch.Util$2)
> 	- locked <0xa519dc20> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xa519dbd0> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> 	at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:366)
> 	at org.apache.http.impl.nio.conn.PoolingClientAsyncConnectionManager.execute(PoolingClientAsyncConnectionManager.java:108)
> 	at org.apache.http.impl.nio.client.AbstractHttpAsyncClient.doExecute(AbstractHttpAsyncClient.java:464)
> 	at org.apache.http.impl.nio.client.AbstractHttpAsyncClient.access$000(AbstractHttpAsyncClient.java:101)
> 	at org.apache.http.impl.nio.client.AbstractHttpAsyncClient$1.run(AbstractHttpAsyncClient.java:485)
> I was originally seeing this issue with beta2 but upgraded to beta3 with no change in
behavior. I'm using httpcore 4.2.2. I also saw this issue https://issues.apache.org/jira/browse/HTTPCORE-315
but I don't think that's causing my issue as I'm not using Futures or canceling them. I'm
using a callback. 
> Additionally in my callbacks (i.e. completed, error, cancelled), I'm renaming the thread
so I could figure out which part of my app might be causing this but none of the orphan threads
seemed to enter the callback because as you see above, they were not renamed. I also grepped
through my logs for the names of the thread and they did not appear to hit any callback.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message