qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Hudalla <sophokles...@gmail.com>
Subject Re: [proton-j] handling of link-credit
Date Thu, 02 Mar 2017 07:51:22 GMT
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message