qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [proton-j] handling of link-credit
Date Mon, 06 Mar 2017 11:23:11 GMT
On 3 March 2017 at 19:31, Alan Conway <aconway@redhat.com> wrote:
> 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.

This mail weirdly turned up a days late :)

> 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.

I'm still not particularly confident that proton-c can handle this
fully either. From some testing Rob did, proton-j definitely doesnt
and as I suspected can do bad things like wrapping credit values and
end up sending massive uint values thinking they are negative (you
cant actually represent negative credit on the wire since its

That said, while in many cases it will behave no differently than a
drain, I do think we should implement support for this eventually,
thats why I raised the JIRA. Peers that dont handle it are one thing,
proton not being able to do it to begin with is another.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message