On 1 March 2017 at 15:29, Kai Hudalla <[email protected]> wrote: > On Wed, 2017-03-01 at 15:07 +0000, Robbie Gemmell wrote: >> On 1 March 2017 at 14:31, Kai Hudalla <[email protected]> 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: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
