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<http://twitter.com/ppatierno> Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno> Blog : DevExperience<http://paolopatierno.wordpress.com/> ________________________________ From: Robbie Gemmell <robbie.gemm...@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.gemm...@gmail.com> wrote: > On 1 March 2017 at 15:29, Kai Hudalla <sophokles...@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...@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-unsubscr...@qpid.apache.org >>> > For additional commands, e-mail: users-h...@qpid.apache.org >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: users-h...@qpid.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
