qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: [proton-j] handling of link-credit
Date Wed, 01 Mar 2017 17:06:20 GMT
On 1 March 2017 at 17:53, Kai Hudalla <sophokles.kh@gmail.com> wrote:

> On Wed, 2017-03-01 at 15:44 +0000, Robbie Gemmell wrote:
> > On 1 March 2017 at 15: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.
> > >
> >
> > 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.
> >
>
> I do not think that this is true. If the sender has e.g. 100 credits left
> and
> indeed has content to send 100 messages then a drain doesn't prevent him
> from
> sending all 100 messages. However, flowing 0 link-credit to the sender has
> the
> effect of immediately stopping him (not considering messages in flight, of
> course). This pattern therefore has the big advantage that a receiver can
> be
> generous at first, issuing e.g. 200 credits, in order to reduce the number
> of
> flows exchanged while things go well, and then simply stop the sender once
> resources become more constrained on the receiver side.
>
>
I don't think your interpretation is correct here.  If the receiver issues
credit for 100 and the sender has 100 messages, then there is nothing
stopping the sender sending all 100 messages before processing the incoming
flow in either case.

Having said that I do think that Proton[-J] should implement reducing
available credit (and I imagine so does Robbie - since he raised the JIRA
to add this feature) since a resource constrained entity may wish to
redistribute/remove credit on links/connections as time passes.



> With the approach currently taken by proton-j this pattern is effectively
> impossible to implement and you always end up with handing out only very
> few
> credits at a time because the receiver always needs to consider potential
> resource constraints or congestion that might occur in the future ...
>
> As above, I think you need to do this anyway.

-- Rob


> > > 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: 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message