Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
MIME-Version: 1.0
In-Reply-To: <1488378679.5694.23.camel@gmail.com>
References: <1488378679.5694.23.camel@gmail.com>
From: Robbie Gemmell <robbie.gemmell@gmail.com>
Date: Wed, 1 Mar 2017 15:07:00 +0000
Message-ID: <CAFitrpSk86938CNTP0a9oB=x_HryAiXVkMzMgMzgNp5_7NZa3Q@mail.gmail.com>
Subject: Re: [proton-j] handling of link-credit
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Wed, 01 Mar 2017 15:07:13 -0000

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.

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.

>
> 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