Producer flow control commented on by Aidan Skinner (Jul 15, 2008).

Comment:

So, splitting this into two different problems, and rescoping to a 0-10 solution, we have two granularities of policy (exchange-level flow control and queue-level flow control) and two levels of security (conforming clients and non-conforming clients).

Dealing with granularity first:

0-10 already defines flow control for exchanges, we can issue message.stop for all producers who are going to publish, allowing further credit when the policy is no longer being violated.

For queue level flow control we should just abandon it and implement exchange+routing key policies instead in AMQP. These would follow the same matching algorithims as the exchanges they are bound to. Message.stop would gain a 'routing-key' argument which would ban the producer from publishing to that combination.

Security can be dealt with by ensuring that violations of message.stop are fatal errors. Extra defensiveness could optionally be introduced by tarpitting the connection like some SMTP servers do.

Policy calculation and administration would probably be best dealt with as part of some sort of management API, but I would imagine it could involve "total size of queues routed to by key" or "maximum size of any queue routed to by key" or variations thereof.

Reply via email to