From dev-return-29307-apmail-activemq-dev-archive=activemq.apache.org@activemq.apache.org Thu Nov 3 16:17:55 2011 Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-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 0FE9C7F48 for ; Thu, 3 Nov 2011 16:17:55 +0000 (UTC) Received: (qmail 26063 invoked by uid 500); 3 Nov 2011 16:17:54 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 25995 invoked by uid 500); 3 Nov 2011 16:17:54 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 25979 invoked by uid 99); 3 Nov 2011 16:17:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 16:17:54 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 16:17:53 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 6C73C32F2AC for ; Thu, 3 Nov 2011 16:17:33 +0000 (UTC) Date: Thu, 3 Nov 2011 16:17:33 +0000 (UTC) From: "Claudio Corsi (Issue Comment Edited) (JIRA)" To: dev@activemq.apache.org Message-ID: <580661821.56243.1320337053457.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1349634262.56236.1320336812248.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Issue Comment Edited] (AMQ-3577) The Connection is not cleanup properly whenever the close method is called within a thread that was interrupted. 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/AMQ-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143273#comment-13143273 ] Claudio Corsi edited comment on AMQ-3577 at 11/3/11 4:17 PM: ------------------------------------------------------------- One more comment, I was able to produce an OOM exception by creating a connection, interrupting the thread and calling the close method in a loop. You can see that the connection was never cleaned up properly and eventually the broker slows to a crawl because of the OOM. With the patch, the broker keeps going without any issues. The main difference is that the thread count is increasing without the fix and with it the thread count does not. A simple workaround is that the user calls does the following: {code} // This will clear the interrupted state to allow the connection to cleanup properly boolean interrupt = Thread.interrupted(); connection.close(); if (interrupted) // This will reset the interrupt state for this thread. Thread.currentThread().interrupt(); {code} was (Author: ccorsi): One more comment, I was able to produce an OOM exception by creating a connection, interrupting the thread and calling the close method in a loop. You can see that the connection was never cleaned up properly and eventually the broker slows to a crawl because of the OOM. With the patch, the broker keeps going without any issues. The main difference is that the thread count is increasing without the fix and with it the thread count does not. A simple workaround is that the user calls does the following: {code} boolean interrupt = Thread.interrupted(); > The Connection is not cleanup properly whenever the close method is called within a thread that was interrupted. > ---------------------------------------------------------------------------------------------------------------- > > Key: AMQ-3577 > URL: https://issues.apache.org/jira/browse/AMQ-3577 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JMS client > Affects Versions: 5.5.1 > Environment: any environment. > Reporter: Claudio Corsi > Fix For: 5.6.0 > > > The connection close method does not properly clean up the connection on the broker. > This is causing a memory leak on the broker because the connection is dangling. > I have not confirmed that trying to call the close method within a non-interrupted thread will properly cleanup the connection after it was already called within an interrupted thread. > I have a test case that reproduces this issue and a patch that corrects the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira