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 Thu, 02 Mar 2017 10:17:08 GMT
On 2 March 2017 at 08:56, Kai Hudalla <sophokles.kh@gmail.com> wrote:

> On Wed, 2017-03-01 at 18:06 +0100, Rob Godfrey wrote:
> > 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:
> > > > > > >
> > > 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.
> >
> No, but the semantics are different, i.e. my interpretation of the spec is
> that
> from the point in time the receiver has sent a FLOW with link-credit 0 it
> is
> entitled to do one of the following when more messages come in:
> - either close the link with the sender ("resource-limit-exceeded") or
> - process a certain amount of "in-flight" messages
> in order to behave in a spec compliant way.
>
>
I think we're probably splitting hairs here :-) As the receiver, we cannot
*know* whether the sender will use up all the credit and send all the
messages, even in the stop case (unless we are also using the session
window to also manage flow, and the session window is "smaller" than the
link credit) so we have to treat the two cases identically.  As a sender we
SHOULD treat the cases differently and endeavour to interleave reads and
writes on a connection so that we are always in possession of the most
up-to-date remote state.

I don't think anyone is disputing that sending a 0 link credit is the
"correct" thing to do; just that at the current time there is no safe way
to do that through Proton-J, and that as the receiver of the messages you
can pretty much treat the cases identically (unless you have a stupidly
large link credit and are really using session windows to manage flow).



> However, if flowing 0 link-credits would simply be considered to mean you
> can
> send 0 more messages than your actual link-credit indicates, then the
> receiver
> would need to be prepared to process all of the "outstanding" messages. Of
> course, the receiver can always release any messages but that is clearly
> not the
> intention of introducing a back-pressure method like the flow control
> specified
> in the AMQP 1.0 spec, is it?
>
>
>
As one of the authors of the AMQP spec, obviously I would prefer if the
proton[-j] implementation was capable of fully expressing all the
behaviours we wrote into the spec, however, given where we are, and the
behaviours that current implementations exhibit, using drain appears to be
the only option.

-- Rob


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