On Wed, 2017-03-01 at 17:04 +0000, Gordon Sim wrote: > On 01/03/17 16:53, Kai Hudalla wrote: > > 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. > > While I agree there is a difference between drain and revoking credit, > even if you issue a flow(0), you still have to handle N messages after > issuing it, where N is balance at the time you revoked it. > That is true and the spec actually describes the receiver's options for this case quite explicitly: either close the link with the sender with a "recource-limit- exceeded" or handle the "in-flight" messages.
> (Since that many messages may already be 'inflight'. As the balance gets > higher it is more likely that the sender gets the flow before they have > exhausted the credit of course.) > > A couple of hundred message credits though is not a lot in this case. > (In my little trial run, if the broker was filled up before I started > the client, it would exhaust the credit - 100 in my case - before > revoking it had any effect). > > If you can't handle the messages normally, e.g. if suddenly wherever you > are putting can't accept them any more, then you can always release > those messages. > Absolutely. > > 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 ... > > > --------------------------------------------------------------------- > 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]
