Return-Path: 
 <users-return-32625-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org>
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 D9772D089
	for <apmail-activemq-users-archive@www.apache.org>;
 Fri, 16 Nov 2012 18:05:50 +0000 (UTC)
Received: (qmail 18392 invoked by uid 500); 16 Nov 2012 18:05:50 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 18355 invoked by uid 500); 16 Nov 2012 18:05:50 -0000
Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@activemq.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@activemq.apache.org>
List-Post: <mailto:users@activemq.apache.org>
List-Id: <users.activemq.apache.org>
Reply-To: users@activemq.apache.org
Delivered-To: mailing list users@activemq.apache.org
Received: (qmail 18347 invoked by uid 99); 16 Nov 2012 18:05:50 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2012 18:05:50 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of juanin@gmail.com designates
 209.85.220.171 as permitted sender)
Received: from [209.85.220.171] (HELO mail-vc0-f171.google.com)
 (209.85.220.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2012 18:05:43 +0000
Received: by mail-vc0-f171.google.com with SMTP id m18so3383159vcm.2
        for <users@activemq.apache.org>; Fri, 16 Nov 2012 10:05:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=wxP0sOkvLaZtAYvx8lFBhSOd7PvE15hwhwdUpkv8WZA=;
        b=XgQRehHMb/qCCyCFk1ub4mIoYSSgiuiTH9sFgmecU2U9pTNmP5n2tVjNYpiMWT9bhm
         5Kopm/xV/z+UugDDvHDtNl4bkAvUzXyr8AhExLWYlMwC59R1w647VWl6fFEM0W3WAAPp
         57VDKz+FOKvKqSRT8z7Lh15UTxq/h30vgodozVfDOjJU/r0wJlXrHb18N+zrx89Ba+gh
         Ihq3gJQnpE22mMHijK9jNDeC8JpJST5kzuKQaeRgiHkRY5+n/r27HkZCewHh974/WF+h
         S9x3xdCa1Rhoi3CQ9HHqbfrHHlOGOlsbAyHEGbxcwFjJ3APm63EzGSS7wsdvMhCj/MFj
         pGAA==
MIME-Version: 1.0
Received: by 10.52.16.179 with SMTP id h19mr4782289vdd.107.1353089122857; Fri,
 16 Nov 2012 10:05:22 -0800 (PST)
Received: by 10.58.124.230 with HTTP; Fri, 16 Nov 2012 10:05:22 -0800 (PST)
In-Reply-To: <F0CFA117-A738-4AF9-A8FC-87AF7E88F495@fusesource.com>
References: 
 <CAL52o-0XY0PfQ5EDhEE_cMgSCLRRvTPssL2XuTW56L-YGiOcfw@mail.gmail.com>
	<F0CFA117-A738-4AF9-A8FC-87AF7E88F495@fusesource.com>
Date: Fri, 16 Nov 2012 16:05:22 -0200
Message-ID: 
 <CAL52o-2iPBdut0wyG6Pn5kW1LFJDFPd73wfXF1qwTSfCLCYkyQ@mail.gmail.com>
Subject: Re: Understanding memoryUsage (once again!)
From: Juan Nin <juanin@gmail.com>
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=bcaec502d7ba84714804cea09c23
X-Virus-Checked: Checked by ClamAV on apache.org

--bcaec502d7ba84714804cea09c23
Content-Type: text/plain; charset=ISO-8859-1

Hi Torsten!

I'm using ActiveMQ 5.3.2, but also tested it on 5.7.0 with the same
results...
This is my 5.3.2 config:

<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:amq="http://activemq.apache.org/schema/core"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
  http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd">

    <bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
            <value>file:${activemq.base}/conf/credentials.properties</value>
        </property>
    </bean>

    <broker xmlns="http://activemq.apache.org/schema/core"
brokerName="localhost" dataDirectory="${activemq.base}/data"
destroyApplicationContextOnStop="true" advisorySupport="false">

        <destinationPolicy>
            <policyMap>
                <policyEntries>
                    <policyEntry topic=">" producerFlowControl="true"
memoryLimit="5mb">
                        <pendingSubscriberPolicy>
                            <vmCursor />
                        </pendingSubscriberPolicy>
                    </policyEntry>
                    <policyEntry queue=">" producerFlowControl="false"
optimizedDispatch="true" memoryLimit="40mb">
                <deadLetterStrategy>
                            <individualDeadLetterStrategy
queuePrefix="DLQ." useQueueForQueueMessages="true" />
                        </deadLetterStrategy>
                    </policyEntry>
                </policyEntries>
            </policyMap>
        </destinationPolicy>

        <managementContext>
            <managementContext connectorPort="2011"/>
        </managementContext>

        <persistenceAdapter>
            <kahaDB directory="${activemq.base}/data/kahadb"
enableJournalDiskSyncs="false" indexWriteBatchSize="10000"
indexCacheSize="1000"/>
        </persistenceAdapter>

        <systemUsage>
            <systemUsage>
              <memoryUsage>
                    <memoryUsage limit="50 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="1 gb" name="foo"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="3 gb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>

        <transportConnectors>
            <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
    <transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>
        </transportConnectors>

    </broker>

    <import resource="jetty.xml"/>

</beans>


Using just a simple PHP script with Stomp for feeding the queues (running
it twice with different queue name):

<?php

require_once("Stomp.php");

$amq = new Stomp("tcp://localhost:61613");
$amq->connect();

for($i=1; $i <= 100000; $i++)
{
if($i%1000 == 0)
{
echo "\nmsg #: $i";
}
$amq->send("/queue/test", "this is test message # $i" ,array('persistent'
=> 'true'));
}

$amq->disconnect();

?>



On Fri, Nov 16, 2012 at 3:47 PM, Torsten Mielke <torsten@fusesource.com>wrote:

> Hello,
>
> See in-line response.
>
> On Nov 16, 2012, at 6:29 PM, Juan Nin wrote:
>
> > Hi!
> >
> > After some heavy digging about Producer Flow control and the systemUsage
> > properties a couple of years ago, I thought I quite understood it.
> > But yesterday I found that one of my configs was not behaving exactly as
> I
> > expected, so started doing some tests, and I see certain behaviours which
> > don't seem to match what the docs and posts that I find on the list or
> > other forums say.
> >
> > "storeUsage" is perfectly clear, it's the max space that persistent
> > messages can use to be stored in disk.
> > "tempUsage"" applies to file cursors on non-persistent messages, so as to
> > flush to disk if memory limits are reached (I don't care much about this
> > one anyway, I always use persistent messages).
>
> Correct.
>
> >
> > Now, according to most posts, memoryUsage would be the maximum memory
> that
> > the broker would be available to use.
> > On this post:
> >
> http://stackoverflow.com/questions/7646057/activemq-destinationpolicy-and-systemusage-configurationit
> > says that "memoryUsage corresponds to the amount of memory that's
> > assigned to the in-memory store".
>
> Correct.
>
> >
> > For example, on my tests using the following config (only showing
> relevant
> > parts):
> >
> > <policyEntry queue=">" producerFlowControl="false"
> optimizedDispatch="true">
> >    <deadLetterStrategy>
> >        <individualDeadLetterStrategy queuePrefix="DLQ."
> > useQueueForQueueMessages="true" />
> >    </deadLetterStrategy>
> > </policyEntry>
> >
> > <systemUsage>
> >    <systemUsage>
> >        <memoryUsage>
> >            <memoryUsage limit="100 mb"/>
> >        </memoryUsage>
> >        <storeUsage>
> >            <storeUsage limit="1 gb" name="foo"/>
> >        </storeUsage>
> >        <tempUsage>
> >            <tempUsage limit="3 gb"/>
> >        </tempUsage>
> >    </systemUsage>
> > </systemUsage>
> >
> > With that config I would expect the broker to use 100 mb of maximum
> memory
> > among all queues. So it could maybe use 30mb in one queue and 70mb in
> > second queue.
> >
> >
> > 1) What I'm seeing is that if I start feeding a queue without consuming
> it,
> > the "Memory percent used" grows up to 70%, after that it doesn't grow
> > anymore.
> > What is it doing exactly there? The first 70% is stored in memory (apart
> > from disk since it's persistent), and all the rest that continues being
> fed
> > goes just to disk?
>
> This behavior is correct. For queues the default cursor is store cursor.
> It keeps any newly arrived msgs in memory as long as it does not reach the
> configured memory limit (either configured on the queue per destination or
> globally in memoryUsage settings).
> Once the cursor reaches 70% of the configured limit (in your case of the
> memoryUsage limit since you don't specify a per-destination limit), it will
> not keep any more messages in memory.
> Instead it will reload these messages from the store when its time to
> dispatch them. The broker anyway persists any msgs it receives before
> passing on to the cursor.
> This limit of 70% can be configured and raised to e..g 100%.
> This behavior is kind of an optimization. That way you run less often into
> producer-flow-control.
> As long as the persistence store is not running full, there is no need to
> block producers, since the cursor can also load the messages from the store
> and does not necessarily have to keep them in memory.
> If you configure the vmQueueCursor, then the behavior is different. This
> cursor will not be able to load msgs to the store but needs to keep them
> all in memory. The vmQueueCursor used to be the default cursor in older
> version of AMQ.
>
> Also note that topic msgs and non-persistent queue messages are not
> handled by the store cursor. These msgs are held in memory and if memory
> runs low, get swapped out to temp storage.
>
> > 2) If then I start feeding a 2nd queue, "Memory percent used" continues
> > growing until it reaches 140%. So it looks like memoryUsage does not
> apply
> > globally, but on a per queue basis?
>
> What version of AMQ do you use? The sum of the memory usage of all queues
> should not go any higher than the configured memoryUsage limit. If you're
> not on 5.5.1 or higher releases, then I suggest to upgrade.
>
> > Using memoryLimit on the queue's policyEntry gives more control over
> this,
> > but it's just a variation, "Memory percent used" can grow more than 100%
> > anyway.
>
> With the default store cursor this should not be the case from what I know.
>
>
> >
> > 3) If #2 is true, then how would I prevent the broker from running out of
> > memory in case queues would continue to be created?
>
> Just like above comment. I would expect the brokers MemoryPercentUsage
> won't grow over 100% and the destinations MemoryPercentUsage remains fairly
> much at 70%.
> Not sure why you would see a different behavior? Using an old version of
> AMQ perhaps? Or explicitly configuring for the vmQueueCursor?
> Could you perhaps also test with
>
> >
> >
> > Maybe I'm misunderstanding and some of these settings make no sense when
> > producerFlowControl is disabled?
> >
> > Thanks in advance.
> >
> > Juan
>
>
> Regards,
>
> Torsten Mielke
> torsten@fusesource.com
> tmielke.blogspot.com
>
>
>
>
>

--bcaec502d7ba84714804cea09c23--