qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [proton-j] handling of link-credit
Date Wed, 01 Mar 2017 17:04:54 GMT
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message