From users-return-17148-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Wed Dec 03 15:30:03 2008 Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 90275 invoked from network); 3 Dec 2008 15:30:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Dec 2008 15:30:03 -0000 Received: (qmail 94819 invoked by uid 500); 3 Dec 2008 15:30:15 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 94550 invoked by uid 500); 3 Dec 2008 15:30:14 -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 94539 invoked by uid 99); 3 Dec 2008 15:30:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2008 07:30:14 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [15.201.24.18] (HELO g4t0015.houston.hp.com) (15.201.24.18) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2008 15:28:43 +0000 Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C4365871B for ; Wed, 3 Dec 2008 15:29:29 +0000 (UTC) Received: from G5W0323.americas.hpqcorp.net (16.228.8.68) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 3 Dec 2008 15:28:22 +0000 Received: from GVW0676EXC.americas.hpqcorp.net ([16.230.33.208]) by G5W0323.americas.hpqcorp.net ([16.228.8.68]) with mapi; Wed, 3 Dec 2008 15:28:22 +0000 From: "Frugia, Kirby A" To: "users@activemq.apache.org" Date: Wed, 3 Dec 2008 15:28:20 +0000 Subject: RE: Broker not releasing memory Thread-Topic: Broker not releasing memory Thread-Index: AclUlgcU+iUn7DJWTP6wX0uHYP6SWwAxQ3YQ Message-ID: <57A2B54B882D5C47B57259B7282A19FF167851625F@GVW0676EXC.americas.hpqcorp.net> References: <57A2B54B882D5C47B57259B7282A19FF16782BC162@GVW0676EXC.americas.hpqcorp.net> <7b3355cb0812020752of373d8do3dbf43837cc26236@mail.gmail.com> In-Reply-To: <7b3355cb0812020752of373d8do3dbf43837cc26236@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org I'm not sure if it would be the prefetch size. The memory usage rightly go= es up when the consumer stops ack'ing messages. The question is, why does = it never go back down when the consumer disconnects? Also, I think changing the message cursor strategy would only prolong the t= ime between failures. Yes, we could start caching messages to disk, but I = would like to know why the messages don't get cleaned up from memory when t= he consumers disconnect (cleanly or not). -Kirby -----Original Message----- From: Bruce Snyder [mailto:bruce.snyder@gmail.com] Sent: Tuesday, December 02, 2008 7:52 AM To: users@activemq.apache.org Subject: Re: Broker not releasing memory On Mon, Nov 24, 2008 at 7:37 AM, Frugia, Kirby A wrot= e: > Hi All, > > Sorry I dual-posted in the dev list. I think I sent to the wrong one... > > We are seeing an issue with our broker not releasing memory on topics. > > Setup: > * Active MQ 5.1 (out of the box) > * Persistent messages sent by publishers > * Non-durable topics > > We were seeing an issue in production with slow consumers causing the bro= ker to run out of memory. > > We wrote a test app, which has one publisher and one subscriber to the sa= me topic. The publisher sends messages on this topic frequently. The subs= criber, upon receiving a message, goes to sleep for 10 minutes. > > Very quickly, the broker runs out of memory. When this happens, our publ= ishers can no longer send messages; the send is blocked. This is expected. = However, if we kill our application (which cleanly disconnects from the br= oker), the broker's memory usage (MemoryPercentUsage) does not go back down= . Also, any new apps that startup will have their publishers blocked. > > Shouldn't the broker release the memory associated with these messages? The first thing to do is configure the prefetch buffer for the client?: http://activemq.apache.org/what-is-the-prefetch-limit-for.html See how that affects the situation. If you're still experiencing issues, you might need to consider using a different message cursor strategy: http://activemq.apache.org/message-cursors.html Bruce -- perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=3D6-E+G-N>61E