Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5D0C37ABF for ; Wed, 20 Jul 2011 14:41:25 +0000 (UTC) Received: (qmail 79695 invoked by uid 500); 20 Jul 2011 14:41:24 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 79635 invoked by uid 500); 20 Jul 2011 14:41:24 -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 79627 invoked by uid 99); 20 Jul 2011 14:41:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Jul 2011 14:41:24 +0000 X-ASF-Spam-Status: No, hits=-0.6 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tabish121@gmail.com designates 209.85.220.171 as permitted sender) Received: from [209.85.220.171] (HELO mail-vx0-f171.google.com) (209.85.220.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Jul 2011 14:41:17 +0000 Received: by vxh11 with SMTP id 11so251288vxh.2 for ; Wed, 20 Jul 2011 07:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=2x3NT8fjY8doisVdr+MoyPVxfr6G0Qi/GBe51eOte5A=; b=YXTgPR1CgIriYv0cRlFZ5fy/iXk1qcM5H2jvTX+2gXtVJYhYOmZ4MfAFerhILzKM+Q rNKGSXKYSKesu+d7Qg+M6jA2JLTQHBC2XI8N5w3hqKMmxv2daeRAgWWOzjs9BRsqRVBD ahhdDx4PA68wpEuD9jio7Tn2JsqxaJ9VC8uag= Received: by 10.52.95.241 with SMTP id dn17mr3014993vdb.35.1311172856392; Wed, 20 Jul 2011 07:40:56 -0700 (PDT) Received: from [192.168.2.150] (c-98-231-181-148.hsd1.va.comcast.net [98.231.181.148]) by mx.google.com with ESMTPS id t14sm78118vcv.29.2011.07.20.07.40.55 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 07:40:55 -0700 (PDT) Subject: Re: Connection close not working when Usage Manager Store is reached Full. From: Timothy Bish To: users@activemq.apache.org In-Reply-To: <3181A30B8C35AB4AA8577B78DDF461380838B372@nickel.mettonigroup.com> References: <3181A30B8C35AB4AA8577B78DDF461380838B372@nickel.mettonigroup.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 20 Jul 2011 10:40:54 -0400 Message-ID: <1311172854.2744.2.camel@office> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit On Wed, 2011-07-20 at 14:24 +0100, Suneel Papineni wrote: > Hi, > > > > I am using ActiveMQ-CPP (v 3.4.0) and ActiveMQ server (v 5.5.0). I am > checking what is going to happen when "StoreUsage" memory limit is > reached 100%. For this I configured "storeUsage" limit as "1 mb" and > tried to send a message. On calling sendMessage, my application got > struck and it is hung state for 10 seconds. After that it thrown an > error saying "No valid response received for command ....." > > (I did configure connection.sendTimeout=10000) > > > > When I try to send message, I could see a INFO message on ActiveMQ which > is shown below > > "Usage Manager Store is Full, 100% of 1048576. Stopping producer..." > > > > At this point as there is an error, I thought of closing connection. > When I called Connection.close() method, application got hung again for > 15 seconds and thrown an error "No valid response received for command: > RemoveInfo {.....", thus making connection not closed properly. I could > see in browser as the connection still exists. Without closing > connection properly, I am unable to reconnect from the application > unless application is closed physically (which in my case is not > possible as the application performs some other operations). > > > > Could someone please let me know why connection is not getting closed at > this time. Also please let me know how should I solve this issue. > > If yuor broker is running out of memory then it might not be able to respond to the remove commands from the client. This shouldn't prevent the client from closing its socket connection though so there could be a bug, however it may just be that the broker is unable to process anything because its out of memory and that's why your connection still shows in the console. It may also be the cause for not being able to reconnect if the broker cannot process the connection commands due to a lack or resources. Some broker logs might help in this instance. You can open a new Jira issue if you believe there is a bug. Regards -- Tim Bish ------------ FuseSource Email: tim.bish@fusesource.com Web: http://fusesource.com Twitter: tabish121 Blog: http://timbish.blogspot.com/