Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1F884D6BD for ; Sun, 7 Oct 2012 16:20:03 +0000 (UTC) Received: (qmail 3152 invoked by uid 500); 7 Oct 2012 16:20:02 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 3122 invoked by uid 500); 7 Oct 2012 16:20:02 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 3113 invoked by uid 99); 7 Oct 2012 16:20:02 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Oct 2012 16:20:02 +0000 Date: Sun, 7 Oct 2012 16:20:02 +0000 (UTC) From: "Mark Greene (JIRA)" To: dev@hc.apache.org Message-ID: <1130837491.6658.1349626802929.JavaMail.jiratomcat@arcas> In-Reply-To: <1000411408.6654.1349626322717.JavaMail.jiratomcat@arcas> Subject: [jira] [Updated] (HTTPASYNC-29) Orphan I/O dispatcher threads MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HTTPASYNC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Greene updated HTTPASYNC-29: --------------------------------- Description: 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. was: 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. > 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