On 1 March 2017 at 15:43, Rob Godfrey <[email protected]> wrote: > On 1 March 2017 at 16: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. >> > > > 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... however I'm not sure that > Proton-J is going to handle this correctly, in particular in the case where > you try to reduce the credit below the amount of credit that has already > been used with messages in flight. > > -- Rob >
I was about to reply to Gordons mail to say the same thing. As per my other mail, proton doesn't really support reducing credit like that. > >> >> > >> > 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? >> >> 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? >> >> >> > > 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]
