Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com
 designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F05EC4D.2040400@blueyonder.co.uk>
References: 
 <CAEqX17MeBpV-j8ADhMPhZwLhaZVWjAgYLV85_1Q+xH4eUHttYg@mail.gmail.com>
	<CAFitrpT7=QxG2ASitwC7+YFuip_e5-bx3L=BU+OTmiDt3zzUvw@mail.gmail.com>
	<CAEqX17PiBZD3HExWYSy=cijzunuMak6WdMe9o_YBTfTVcfqpEA@mail.gmail.com>
	<CACsaS941EW4BFJr0=3X9k1sD1-orankYqD94RxVBrOyyaHjx+Q@mail.gmail.com>
	<CAEqX17NN_PT41B2sM9mFK925jpLnHOTpk1GjN5YBfN1wEo26BQ@mail.gmail.com>
	<4F05EC4D.2040400@blueyonder.co.uk>
Date: Thu, 5 Jan 2012 19:57:56 +0100
Message-ID: 
 <CACsaS97sEgRGm-gjZzxGPZDmmeRG7WNbzgHrNptQ1+_WChYTPg@mail.gmail.com>
Subject: Re: Qpid Java Broker with persistance supports only finite number of
 messages?
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: users@qpid.apache.org
Content-Type: multipart/alternative; boundary=0016e6d58a7fa1f69e04b5cc82eb

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

On 5 January 2012 19:30, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:

> Just to jump in on this thread.
>
> Re "
>
>
> but my opinion
> is that if you have "millions of messages" then a Message Broker is the
> wrong solution to your problem - you want a Database.
>
> "
> I can't say I agree with Rob's assertion here!!
>
> Well maybe that's a reasonable comment if the *intention* is to have
> millions of messages hanging around, but what if it's due to an unfortunate
> circumstance......
>
>
Indeed - that is what I meant :-)  Planning for failure scenarios should
always be carefully considered... As Robbie mentioned we have had people
build up millions of messages on persistent queues... and if you use the
64-bit JVM and put large amounts of RAM in your box, then the physical
limitations of maximum queue size can be made acceptably large... However I
would always caution against designing a system where you expect to hold
this number of *persistent* messages as part of your regular process -
especially using the Java Broker as it is not designed for this sort of use
case.

The case you describe is somewhat different in that you are looking at
transient messages (where one would expect the rate of
production/consumption to be higher), and you want the broker to be capable
of buffering for N minutes while temporary network outages occur.  Flowing
to disk may make sense here as long as the rate at which messages can flow
through the disk is higher than the rate at which they are entering the
broker (and actually high enough so that the backlog can quickly be
reduced).  This is where the flow-to-disk work that I hope to be starting
soon on the Java Broker would play.

-- Rob

--0016e6d58a7fa1f69e04b5cc82eb--