On Wed, 2017-03-01 at 15:45 +0000, Robbie Gemmell wrote: > > That is a correct understanding of the AMQP 1.0 spec (section 2.6.7 > > specifically deals with this case of credit being revoked: "If the > > link-credit is less than or equal to zero, i.e., the delivery-count > > is the > > same as or greater than the delivery-limit, a sender MUST NOT send > > more > > messages. If the link-credit is reduced by the receiver when > > transfers are > > in-flight, the receiver MAY either handle the excess messages > > normally or > > detach the link with a transfer-limit-exceeded error code.") > > > > As Gordon suggested separately, the logical thing to do through the > > Proton > > API would be to try to flow negative credits...
I would *strongly* suggest that if you want to stop a sender with too much credit you should close the link. The inconvenience of re- establishing the link will be nothing to the hell you will enter if you try to implement negative credit. It is theoretically possible and allowed by the spec, but the chances that any application you are connected to will implement it properly are slim to none. The concept of credit is clear and simple when you see it as a promise between sender and receiver that must not be broken *in either direction*. Revoking credit is breaking half the promise. The more elaborate AMQP view of "credit" where it can be negative (debit?) is mathematically sound but pragmatically a bad idea. > > however I'm not sure that > > Proton-J is going to handle this correctly, See? See? I am fairly certain that almost nobody will handle this correctly. Proton-C provides the tools, but you have to get the book- keeping right, and have faith that every application you connect to will as well. That is a bad bet. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
