On 1 March 2017 at 22:13, Gordon Sim <g...@redhat.com> wrote: > On 01/03/17 21:09, Rob Godfrey wrote: > >> On 1 March 2017 at 19:28, Gordon Sim <g...@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. >>> >>> >>> >>> OK - so do we ever expect Proton to cry foul if the sender sends beyond >> any >> credit that it could reasonably be expected to have seen - or would we >> leave this up to the application to detect? >> > > That's a good question. I ran the test to see what would happen, half > expecting proton to end the link with an error. If it does nothing at all > to enforce the credit limit (even when not revoking previously granted > credit), that is probably a concern. Would need a more involved test to > determine that. > > My gut feeling says that the library (Proton) should detect the error if it can determine that the other party has sent beyond any limit it might possibly still believe to be true... which (in the simplest form) might just mean retaining a high watermark of acceptable delivery count... I don't personally think we should be expecting the application to write logic to detect ill behaving producers... but I'm not sure what the original intent of Proton was here.
-- Rob > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
