[rabbitmq-discuss] Message Priority & 'Headers' Exchange Type (was: Net::AMQP Perl Client - Status?)
Tony Garnock-Jones
tonyg at lshift.net
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
More information about the rabbitmq-discuss
mailing list