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: <CAFitrpR7fgdRtktTp9y8DzusQ_XNmW++Ud+dRLtxGqk=_FhXGg@mail.gmail.com>
References: <1488378679.5694.23.camel@gmail.com> <ed6b3351-f7ad-ebe8-ab28-b3fd1880b56f@redhat.com>
 <2c42870f-fb03-e26a-f046-5caf6e1d1609@redhat.com> <CAFitrpRqwgUbDRVWvGXsOi5k1h1HsjEgc8=g_unc=7boUsdqVw@mail.gmail.com>
 <3aaeeef5-0edd-2e7a-83ba-8f33bef87663@redhat.com> <CAFitrpSWheJTALnsewr0DDK1+MsrX-n_U4Y8r8Mf7pNd7simRg@mail.gmail.com>
 <a56d8025-4d42-9566-9859-fa9f0abb9475@redhat.com> <CACsaS978_j40aBZ8Z-ACvBh4BNp-p6XVTAB_XZTxwy-23UHsww@mail.gmail.com>
 <d80b0e68-c733-0ba6-ad66-708adc32e8b6@redhat.com> <CAFitrpR7fgdRtktTp9y8DzusQ_XNmW++Ud+dRLtxGqk=_FhXGg@mail.gmail.com>
From: Rob Godfrey <rob.j.godfrey@gmail.com>
Date: Thu, 2 Mar 2017 13:06:57 +0100
Message-ID: <CACsaS971JQB2BZ=E3tdXVHCRSt_tKBuRqr3-offKYg_N=BaxtQ@mail.gmail.com>
Subject: Re: [proton-j] handling of link-credit
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=001a114e6ace14590d0549be4477
archived-at: Thu, 02 Mar 2017 12:07:06 -0000

--001a114e6ace14590d0549be4477
Content-Type: text/plain; charset=UTF-8

On 2 March 2017 at 12:56, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:

> On 1 March 2017 at 18:28, Gordon Sim <gsim@redhat.com> wrote:
> > On 01/03/17 18:14, Rob Godfrey wrote:
> >>
> >> The link credit is an absolute value on the wire... but proton presents
> it
> >> in relative terms.  If you had 500 units of credit outstanding and
> >> flow(-500) and then flow(2), and you get 5 messages on the wire arriving
> >> after that point... what state is your link credit in in Proton?
> >
> >
> > I would expect it to be 0.
> >
> >> Does it
> >> make a difference if those 5 messages had been processed by Proton (but
> >> not
> >> received by the application) before the flow(2) was sent or not?
> >
> >
> > Yes, if the flow(2) was issued after the 5 messages were processed, I
> would
> > expect the credit to be 2.
> >
>
> I think we need to be clearer what we mean by 'in proton' when
> discussing this - at the application level, or the transport/wire
> level, and before or after the application processes received
> messages, as these are all potentially in different states /
> presenting different views/values for credit at a given time. Indeed
> doing any of this inside e.g the container/reactor will often give a
> different result than it would in e.g the JMS client, since the
> effects of operations will actually occur at different times.
>
> I'm not sure most of them will currently match your expectations,
> credit will actually end up negative in a lot of them. Note in your
> example, when the timer refreshed credit by doing flow(100) the link
> credit on the wire actually went to 74, because 3 messages were
> received/buffered and processed at the receiver before it actually
> sent the flow reducing credit to 0, then 26 in flight were processed
> after, making credit end up at -26 once they were all processed,
> giving an effective 74 later when the flow(100) occurred to 'add 100'
> credits.
>
> Ignore proton for a minute and consider the following at a protocol
> level. If as a sender you get a flow saying delivery-count is 0 and
> credit is 100, and send 50 messages in-flight, then get a flow
> indicating delivery-count is 10 and credit is 0, then receive a flow
> indicating delivery-count is 20 and credit is 10, what is your actual
> credit at the sender and receiver when all is done?


So at this point I would say that the sender considers credit to be 0
(there's no point in the sender trying to store a negative link-credit
amount), at the receiver the link credit is (the most recent delivery-count
it saw from the sender) - 30 (this value may be negative).


> The receivers last
> flow had just said credit is 10, but the senders delivery-count is
> already 30 beyond what it could ever become based on that flow, so
> credit should actually be -30 at the sender now. The receiver also
> doesn't just end up at 0 after getting 10 more messages based on its
> last flow, and instead has to cope (or fall over and close the link)
> when an additional 20 more messages arrive than it seemingly just gave
> credit for; despite having previously reduced credit from 100 to 0 and
> increasing it back to 10 after receiving 20 messages, 30 more messages
> arrived since it never found out if the reduction to 0 took effect and
> it turns out that 50 (or even up to 100) were sent using the original
> credit before it adjusted the credit twice more. Suppose we say that
> the receiver actually successfully processes all 50 messages despite
> that, this makes its delivery-count now 50 as well, what is its
> credit?
>
>
I think here there are two separate considerations... On the wire I would
think that the receiver should update its delivery count to reflect the
last received delivery from the sender (unless it just decides to tear down
the link), and I would expect that the link-credit at this point would be
zero.

More interesting to me is how we handle this in the interaction between the
library and application layers.  Does the application layer have to issue
more credit before the library presents the deliveries to it (even though
the library is already holding the deliveries).  If not then does the
application layer have to issue retrospective credits in order to start
receiving new messages?

I'm not sure the accounting part is hard... it's getting the API right that
seems more tricky to me.

-- Rob


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

--001a114e6ace14590d0549be4477--