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