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.
(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.
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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
