On 1 March 2017 at 16: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. > 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 > > > > > 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: 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 > >
