On 29/01/07, Alan Conway <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-29 at 17:53 +0000, Gordon Sim wrote:
> Alan Conway wrote:
> > That raises an interesting question: should AMQP support (custom) Queue
> > types?
>
> There is an 'arguments' field of type table that could be used to
> indicate queue type (or desired characteristics) albeit in a
> non-standard way.
That is true. However the question remains - is it better to provide a
single Queue class that does everything (including replay) or a
selection of Queue classes with different features? I'm not sure of the
right answer. I am leaning towards the swiss-army-queue because AMQP
does not provide any way to compose features, so separate Queues would
suffer from the "but I want it to do X AND Y" problem and because I'm
guessing the list of things that anyone would want to a queue to do is
bounded and fairly small - but I'm not sure of that last point either
yet.
Cheers,
Alan.
You could of course dynamically change the type of queue in use
depending on the usage. e.g. We could write a queue that is slightly
more efficient when you don't have queue browsers or JMS selectors but
when a client connects that requests this then the DeliveryManager
(The guts of our AMQ Queue) could be changed as "normally" there is no
list of messages. I say "normally" as you only have a list stored on
the broker when there are no consumers or not sufficiently fast
consumption.
--
Martin Ritchie
