[rabbitmq-discuss] Robust zone-aware topology?

Mordy Ovits mordyovits at yahoo.com
Fri Feb 28 15:08:01 GMT 2014


> As the sentence you quoted states, the criteria for when messages are

> pulled down is threefold. In particular note the last part, i.e. "the
> upstream queue has 'spare' messages that are not being consumed". 
> In other words, messages are only pulled to the downstream if the
> upstream consumers cannot keep up.

But doesn't that mean that downstream won't help out an upstream when downstream is actively moving messages, even if upstream is not being drained?  IOW, if consumers in Miami are happily taking messages from the miami queue, they won't steal messages from the new_york queue even if the consumers in New York are down and new_york is filling up?  And couldn't a slow day in Miami (no jobs for them) cause the consumers in Miami to start picking off messages from new_york, unnecessarily causing cross-zone work cost?  I don't want consumers in Miami to do New York work just because new_york has a queue depth of 2 while miami is quiet.

Federated queues seem like a pull behavior for LB/throughput, but HA is more of a push behavior; when a exchange is in trouble, it pushes its messages elsewhere.

> Right, so in the event that upstream consumers cannot keep up, messages 
> would be pulled to the downstream and processed by downstream consumers, 
> albeit more slowly. That results in a higher overall throughput than 
> leaving the messages on the upstream. Can't see what's wrong with that.

I'm not looking for increased throughput, at least not at the expense of zone-locality of messages.  I want messages to stay local to a zone unless it simply can't be handled there.  Miami isn't very far from New York, but Singapore is.  I think my alternate-exchange design accomplishes that, but I'm concerned about a-e routing loops (still unexplained).

Thanks,
Mordy



More information about the rabbitmq-discuss mailing list