On 1 March 2017 at 18:04, Gordon Sim <g...@redhat.com> 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. > > (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.
Only if the sender supports that outcome. It would be nice if standard clients dealt automatically with a server "releasing" messages by simply storing them for replay, but I have my doubts as to whether many of them do. For added complexity, of course, if those messages are sent transactionally and settled then the "correct" course of action might be to force the transaction to roll-back. Or one might decide that the simplest course of action for dealing with senders who breach their credit limits (even if they didn't know that they had done so) would be to force a disconnection / reconnection. -- Rob > > > 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 > >
