Mark Greene created HTTPASYNC-29:
------------------------------------

             Summary: 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-beta3, 4.0-beta2
         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. 


--
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to