Mailing-List: contact qpid-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: qpid-users@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.j.greig@gmail.com
 designates 209.85.134.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=PoLlxLvIOsVrm4k9bh2w2tkZR1lC6lNj/jzSJItJ8YcjaIWjqUq0B0FLugfgnSfSdA
         605Hzvk44HBxaEbLvwFBmSegKaW9SCtNnYCIWzE5sdziPhJOGNL/2/UfXH/RRKKLEsKV
         7sc0U7CMnZHyVKKfN6/M7yIBPB/SDkTdVQGjI=
Message-ID: <129a14790811081006j2d2d3ad1j2a11e7801dd9fb3@mail.gmail.com>
Date: Sat, 8 Nov 2008 18:06:32 +0000
From: "Robert Greig" <robert.j.greig@gmail.com>
To: qpid-users@incubator.apache.org
Subject: Re: Java M3 Qpid broker memory consumption
In-Reply-To: <129a14790811080544v10b2072bo2ebb63bf8bb006f7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e8e1811c0811010236o1d8d328bt2b86ce6ff506fe3d@mail.gmail.com>
	 <129a14790811020816u401c72d9j9a7e0ac66d1a7a39@mail.gmail.com>
	 <e8e1811c0811030155y6b69111et49eefb6c91cdea71@mail.gmail.com>
	 <129a14790811031241q4e7f08ach43d0a5da8ba2f2d4@mail.gmail.com>
	 <49102118.40901@redhat.com>
	 <129a14790811051249y391f39cejf6f89bb70c42998c@mail.gmail.com>
	 <49120CBE.5070709@redhat.com>
	 <e8e1811c0811072015g2a92fdd6pd4427cdeeb22374f@mail.gmail.com>
	 <129a14790811080544v10b2072bo2ebb63bf8bb006f7@mail.gmail.com>

2008/11/8 Robert Greig <robert.j.greig@gmail.com>:

> This is not a particularly good solution from a performance
> perspective since the broker will make a lot more system calls as a
> result - particularly when you have smaller messages. However with a
> low rate such as 200 messages/second this should be fine I think.
>
> If you try this, you should see that messages do build up in the queues.

I meant to mention that one reason you would want to do this is that
it should lower the memory consumption of the broker. The reason for
that is due to a performance optimisation that the broker does. If the
broker thinks it can push a message straight out to a consumer, it
just takes a slice of the heap buffer used to read from the socket -
which will be 32k by default. This is to avoid the overhead of copying
to another buffer. Note that the broker does think it can push the
message straight out to a consumer because what MINA is doing is
hidden.

If the messages are kept on a queue, then it will copy them to an
appropriately sized buffer to reduce memory consumption. In your case
where your messages are 250 bytes this will be particuarly noticable.

RG