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 Thu, 02 Mar 2017 11:56:50 GMT
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'

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? 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
doesnt 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 sucessfully processes all 50 messages despite
that, this makes its delivery-count now 50 as well, what is its

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

View raw message