On 1 March 2017 at 18:28, Gordon Sim <[email protected]> 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? 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 credit? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
