[rabbitmq-discuss] Message Priority & 'Headers' Exchange Type (was: Net::AMQP Perl Client - Status?)
0x6e6562 at gmail.com
Wed Jan 14 19:59:40 GMT 2009
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
Yep, sure is. And will get done some time :-)
More information about the rabbitmq-discuss