<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 8 Nov 2007, at 07:30, Brian Granger wrote:</div><blockquote type="cite">This question definitely makes sense. In our system some types of<br>messages can only be consumed by particular workers. These message<br>bypass any load balancing. For these types of messages the producers<br>do need to be able to do things like 1) discover which consumers are<br>currently available 2) send messages to specific consumers and 3) get<br>back results from those consumers.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>Point 3 sounds like asynchronous RPC, for which there is already a pattern.</div><div><br class="webkit-block-placeholder"></div><div>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. </div><br><blockquote type="cite"><blockquote type="cite">Hence I was asking whether it had<br></blockquote><blockquote type="cite">to be producer driven rather than consumer driven.<br></blockquote><br>It is definitely producer driven in the sense the the producer is the<br>one making decisions about where to send what types of messages.</blockquote><div><br class="webkit-block-placeholder"></div><div>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. </div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font>There is definitely conversational state between producers and<br>particular consumers. The consumer's also maintain a lot of internal<br>state. You could even look at our consumers as state machines that<br>change state in response to the messages.<br></blockquote></div><br><div>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.</div><div><br class="webkit-block-placeholder"></div><div>Ben </div></body></html>