On Wed, 2017-03-01 at 18:06 +0100, Rob Godfrey wrote: > On 1 March 2017 at 17:53, Kai Hudalla <[email protected]> wrote: > > > On Wed, 2017-03-01 at 15:44 +0000, Robbie Gemmell wrote: > > > On 1 March 2017 at 15:29, Kai Hudalla <[email protected]> wrote: > > > > On Wed, 2017-03-01 at 15:07 +0000, Robbie Gemmell wrote: > > > > > On 1 March 2017 at 14:31, Kai Hudalla <[email protected]> > > > > 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.
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? > 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: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > > > --------- > > > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
