0-10:
Flowing producers individually is probably a better idea, although it would require tracking who's used what routing keys as well as what routing keys end up on which queues.
> 0-10:
Holding back completion notification seems insufficent to me, you'd run into the same problem described above where you could end up with an extra message per producer on the queue and the producer wouldn't know why the ack hasn't come back. TCP flow control is a bit better, but has the problem that you're flowing the whole connection, which could cause problems if a data queue is full and would get emptied by a consumer which is awaiting a 'go' message on a control queue. I think a finger grained notion of destination is the right answer, and one that makes a lot of things a lot clearer. Is there an AMQP Jira that talks about this?
< 0-10:
TCP flowing connections that have exceeded a high water mark for jobs, and unflowing once it hits a low water mark seems sensible, but we'd need a fair amount of additional accounting information to implement this.
Flowing on the channel is more problematic, it would require much of the same machinery from the 0-10 case but wouldn't be as granular. Oh well.
