[rabbitmq-discuss] Queue inspector.
0x6e6562 at gmail.com
Thu Nov 8 08:42:28 GMT 2007
On 8 Nov 2007, at 07:30, Brian Granger wrote:
> This question definitely makes sense. In our system some types of
> messages can only be consumed by particular workers. These message
> bypass any load balancing. For these types of messages the producers
> do need to be able to do things like 1) discover which consumers are
> currently available 2) send messages to specific consumers and 3) get
> back results from those consumers.
If certain types of messages have to be processed by particular
consumers, this could be achieved by having consumers bind to
different queues, I think. It also sounds like a use case for using
predicates in header based routing, which unfortunately is not
currently implemented in rabbit.
Point 3 sounds like asynchronous RPC, for which there is already a
Points 1 and 2 sound like they are required to support point 3, but
I'm still failing to see the concrete business requirement for that,
but having said that, I don't understand your domain.
>> Hence I was asking whether it had
>> to be producer driven rather than consumer driven.
> It is definitely producer driven in the sense the the producer is the
> one making decisions about where to send what types of messages.
Thats why I was asking whether you can turn the decision on it's head
by just having the producers fire and forget and letting the consumers
dequeue messages based on some predicate.
> There is definitely conversational state between producers and
> particular consumers. The consumer's also maintain a lot of internal
> state. You could even look at our consumers as state machines that
> change state in response to the messages.
Fair enough. If you do need to maintain a conversation between a
producer and consumer over multiple message exchanges then I can see
why things might have to be determined by the producer.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss