I had the same question for Robbie few months ago ... and of course he replied me in the same way 😊


Sending flow(0) as AMQP 1.0 allows is not provided by proton-j

Neither reducing credits with a negative value

Finally the only way could be using drain or just granting 1 credit at time ... but of course with poor performance !


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: Robbie Gemmell <robbie.gemmell@gmail.com>
Sent: Wednesday, March 01, 2017 3:49 PM
To: users@qpid.apache.org
Subject: Re: [proton-j] handling of link-credit
 
On 1 March 2017 at 15:44, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
> 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.
>

Or, if I took the full context into account, I would instead have
said: also look at getQueued() to consider locally queued deliveries.

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