[rabbitmq-discuss] Message Priority & 'Headers' Exchange Type (was: Net::AMQP Perl Client - Status?)

[Ben Hood]

Darien,

On Wed, Jan 14, 2009 at 7:47 PM, Darien Kindlund <darien at kindlund.com> wrote:
> Understood.  I would say message prioritization would be exceedingly
> useful from an operational perspective.   This is something normally
> that each AMQP-aware application we implement would benefit from.
> Otherwise, we'd have to create different queues per priority and have
> the app monitor each queue in priority-based order.  Not impossible to
> implement, but not ideal.

Noted. As I said before, we are slowly getting around to doing this -
it's on the mid-term radar and we already have a design for it. It's
just that some other major queue related work is being asked for a lot
more loudly that priorities.

> Taking that type of implementation to the next logical step:
> 1) Is there any way to perform "non-blocking" SUBSCRIBEs via
> Net::Stomp to RabbitMQ, in order to have a perl consumer application
> monitor multiple queues in series?  Or, is the recommendation to use
> something like ithreads to create a separate thread per subscription
> and multiplex the messages manually within the application?  (See what
> I mean, by increased complexity costs on the app?)

I'll let Tony comment on the semantics of STOMP.

> The 'headers' exchange type comes in handy as a customizable
> specification.  Yes, we can 'transcode' requirements like (Foo: A,
> Bar: B) into queues with routing keys of (foo.*.bar.*), but that gets
> awkward for really long lists of headers.  With the
> 'message.destination' size of 'str8', that's 255 UTF-8 chars, so it
> doesn't scale nicely.  Though, it's not a show stopper for initial
> use.

Yep, sure is. And will get done some time :-)

Ben