Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 41746 invoked from network); 10 Sep 2008 16:08:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Sep 2008 16:08:32 -0000 Received: (qmail 6049 invoked by uid 500); 10 Sep 2008 16:08:29 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 6028 invoked by uid 500); 10 Sep 2008 16:08:29 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 6016 invoked by uid 99); 10 Sep 2008 16:08:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Sep 2008 09:08:29 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=GAPPY_SUBJECT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [195.110.126.54] (HELO mail.dada.it) (195.110.126.54) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 10 Sep 2008 16:07:30 +0000 Received: (qmail 14841 invoked from network); 10 Sep 2008 16:06:57 -0000 Received: from unknown (HELO ?192.168.243.135?) (195.110.97.5) by mail.dada.it with SMTP; 10 Sep 2008 16:06:57 -0000 Message-ID: <48C7F170.50203@staff.dada.net> Date: Wed, 10 Sep 2008 18:10:24 +0200 From: Yari Marchetti Organization: Dada.net User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: users@activemq.apache.org Subject: The connection to x.x.x.x:x is taking a long time to shutdown X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, today i was testing a client application with ActiveMQ broker using STOMP transport, and after some tests i saw 27 different consumers connected to that queue by looking at the web console. This is impossible because the broker is on my machine and i was the only one accessing it. By looking at netstat i saw 27 CLOSED_WAIT different connections to the stomp transport port, and the clients were all gone by long. So i tried to stop the broker and got an unending list of The connection to '/x.x.x.x:x' is taking a long time to shutdown repetead by 5 seconds, and the broker never stopping so that i had to kill it. The tests were somewhat unusual, with a lot of abruptly interruptions, but i think this isn't the normal behavior for the broker, isn't it? greetings, Yari