Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 64.233.170.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Fbcjx2qf0XvU5o+eRBLklYmHSHBYIa+xR8cRCLumedaZvwV/I35yaWmtrserqxt9gcNFSpg5Nf31kGwNdrMBcDkKEIa2C8A+M/lYU1EXJsNutcw4zTWDsX9v8F3oVMYdcFrEiiKTmfqWD7w3eudtfAN3um7/P01KUZw6wE68zGI=
Message-ID: <ec6e67fd0712050813g7e40c8f1jf2ec04f1e359379e@mail.gmail.com>
Date: Wed, 5 Dec 2007 16:13:19 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: users@activemq.apache.org
Subject: Re: Questions on Network of Brokers and high message rates
In-Reply-To: <14174653.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <14145093.post@talk.nabble.com> <14161300.post@talk.nabble.com>
	 <14165394.post@talk.nabble.com>
	 <ec6e67fd0712050626k6c2ad62fqf5d952bc4e1afefd@mail.gmail.com>
	 <14173515.post@talk.nabble.com>
	 <ec6e67fd0712050726t5e586f84qfd7773f69b7a6bdf@mail.gmail.com>
	 <14174653.post@talk.nabble.com>

On 05/12/2007, Marc Zampetti <zampettim@aim.com> wrote:
> James,
>
> Yes, it sounds like the JEDI thing and the partitioning approach is what I
> need. And yes, I'm talking queues for the most part.  For the partitioning,
> is that something that AMQ, or are you talking about me having a layer in
> front of AMQ that would do this.

Its a pending feature request - basically a custom Transport inside
ActiveMQ to do the partitioning.
http://issues.apache.org/activemq/browse/AMQ-816


> In this case, instead of having one big
> network of brokers, I would have several smaller networks of brokers?

So a network of brokers is for store and forward; each subscription
must be replicated across each broker so messages can be stored and
forwarded from broker to broker. When talking about massive load, you
generally don't wanna forward messages from one broker to another (as
you're already overloading a single broker - you don't wanna send 2x
or 3x the traffic due to store/forward).

However you don't need that - what you need is producers partitioning
(or just load balancing) across a number of brokers. i.e. its just a
number of brokers thats all. Then ensuring that there are sufficient
consumers connected to each broker.

e.g. each one of your 50 producers could load balance across, day, 10
brokers. Then each 10 broker has a 100-5000 consumers processing
requests concurrently (depending on how fast/slow it is to process
messages).

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com