qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [proton-j] handling of link-credit
Date Wed, 01 Mar 2017 15:45:42 GMT
On 1 March 2017 at 15:43, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 1 March 2017 at 16: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.
>>
>
>
> 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: 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


Mime
View raw message