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

Wed Jan 14 23:44:36 GMT 2009

Darien Kindlund wrote:
> Understood.  I would say message prioritization would be exceedingly 
> useful from an operational perspective. [... a workaround is] Not
> impossible to implement, but not ideal.

Agreed.

> 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 don't think there's any restriction on the number of active SUBSCRIBEs 
you can have in a single connection. (As an aside, if you supply the 
"id" header on each SUBSCRIBE, the server will attach a "subscription" 
header on corresponding MESSAGEs, which can sometimes be useful when you 
have more than one SUBSCRIBE active at a time.)

> 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.

Agreed.

Regards,
   Tony