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 Wed, 01 Mar 2017 15:44:30 GMT
On 1 March 2017 at 15:29, Kai Hudalla <sophokles.kh@gmail.com> wrote:
> On Wed, 2017-03-01 at 15:07 +0000, Robbie Gemmell wrote:
>> On 1 March 2017 at 14:31, Kai Hudalla <sophokles.kh@gmail.com> wrote:
>> > Hi,
>> >
>> > we are working on the Eclipse Hono project where we use vertx-proton and
>> > (implicitly) proton-j under the hood for exchanging large amounts of messages
>> > using AMQP 1.0.
>> >
>> > During our tests I stumbled across the way that proton-j seems to handle
>> > link-
>> > credit being exchanged via FLOWs.
>> > My understanding is the following:
>> >
>> > Assuming that we have a link established between a Receiver (r) and a Sender
>> > (s)
>> > with a current link-credit of 4 and a delivery count of 20 on both sides.
>> >
>> > When invoking r.flow(6), the given credit (6) is _added_ to the receiver's
>> > current credit resulting in r.getCredit() returning 10.
>> >
>> > When the FLOW is then flushed to the sender, the sender seems to _add_ the
>> > link-
>> > credit from the FLOW to its already existing credit. Analogously, this
>> > results in
>> > s.getCredit() now returning 10.
>>
>> Correct. In proton the flow(credits) method grants additional credits.
>>
>> >
>> > With this approach, it doesn't seem to be possible to stop the sender from
>> > sending messages. The only thing a receiver can do is to wait until the
>> > sender
>> > has used up all its credit (which may be a lot given that with the current
>> > approach the sender's credit can pile up substantially).
>> >
>> > Or am I mistaken?
>>
>> Granting credits is essentially giving the sender ability to send that
>> many messages. If you are controlling credit, any 'pile up' of credit
>> at the sender is one that you create yourself - if you dont want the
>> sender to be able to send more than a certain number of messages at a
>> given time, dont allow more than that number of credits to be
>> outstanding at the time.
>
> So, still, there is no way to stop a sender from sending once it has credit and
> wants to send messages, right? My understanding of the AMQP 1.0 spec is that it
> should be possible to do so by flowing a link-credit of 0 to the sender.
>

Correct, it does. Proton doesnt really support reducing credit.

https://issues.apache.org/jira/browse/PROTON-796

>>
>> One thing you may not be aware of is you can drain the link of
>> existing credit, which essentially asks the sender to send what they
>> can (something they typically will have already done if they have
>> credit and anything to send) then spontaneously advance the delivery
>> count to the extent needed to use up all outstanding credit.
>>
>
> I am aware of this but it also doesn't help with stopping a sender that is
> already sending, does it?
>

To a large extent its little different than setting credit to 0; if a
sender already has credit and content to send you then they can
already send it, and are likely to do so before receiving a flow frame
setting credit back to 0.

> My understanding of all of this is that a Receiver should not grant much credit
> to a Sender (because it cannot stop the sender once it has started sending).
> Then, when a message is coming in, the receiver should check whether there is
> credit left for the sender (using Receiver.getCredit() ?) and if not it should
> grant some more credit using Receiver.flow(small number) again.
>
> Does that make sense?
>

As above, you should grant only as much outstanding credit as you are
actually willing for a sender to use at a given time. The above would
be one way to do it. You can also look at getRemoteCredit, which takes
locally-queued deliveries into account as well.

>
>> > Also, I cannot find the code where the link credit is actually updated from
a
>> > FLOW received from a Receiver. Can you point me to the right class?
>> >
>>
>> TransportSender is probably what you want.
>>
>> > Regards,
>> > Kai
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

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


Mime
View raw message