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 15:56:35 GMT
On 01/03/17 15:37, Gordon Sim wrote:
> On 01/03/17 14:31, Kai Hudalla wrote:
>> Assuming that we have a link established between a Receiver (r) and a
>> Sender (s)
>> with a current link-credit of 4 and a delivery count of 20 on both sides.
>>
>> When invoking r.flow(6), the given credit (6) is _added_ to the
>> receiver's
>> current credit resulting in r.getCredit() returning 10.
>>
>> When the FLOW is then flushed to the sender, the sender seems to _add_
>> the link-
>> credit from the FLOW to its already existing credit. Analogously, this
>> results in
>> s.getCredit() now returning 10.
>>
>> With this approach, it doesn't seem to be possible to stop the sender
>> from
>> sending messages. The only thing a receiver can do is to wait until
>> the sender
>> has used up all its credit (which may be a lot given that with the
>> current
>> approach the sender's credit can pile up substantially).
>>
>> Or am I mistaken?
>
> Can you specify a negative value to Receiver::flow()? I.e. would that
> subtract from the credit and send a corresponding flow to the sender?

That seems to work for proton-c which has a similar API. (Not ideal, but 
a workaround at least).

> $ PN_TRACE_FRM=1 python revoke_credit.py
> [0x563feb999040]:  -> SASL
> [0x563feb999040]:  <- SASL
> [0x563feb999040]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS,
:PLAIN]]
> [0x563feb999040]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"anonymous@localhost.localdomain"]
> [0x563feb999040]:0 <- @sasl-outcome(68) [code=0]
> [0x563feb999040]:  -> AMQP
> [0x563feb999040]:0 -> @open(16) [container-id="023946f1-0197-4559-bd72-7fff5a687958",
hostname="localhost", channel-max=32767]
> [0x563feb999040]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
> [0x563feb999040]:0 -> @attach(18) [name="023946f1-0197-4559-bd72-7fff5a687958-examples",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
> [0x563feb999040]:  <- AMQP
> [0x563feb999040]:0 <- @open(16) [container-id="a6022696-2483-49f5-8ea6-a6f50db0e7ae",
channel-max=32767, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], properties={:product="qpid-cpp",
:version="1.36.0", :platform="Linux", :host="localhost.localdomain"}]
> [0x563feb999040]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
> [0x563feb999040]:0 <- @attach(18) [name="023946f1-0197-4559-bd72-7fff5a687958-examples",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
durable=0, timeout=0, dynamic=false, distribution-mode=:move], target=@target(41) [durable=0,
timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x563feb999040]:0 -> @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=100, drain=false]
> [0x563feb999040]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x00\x00\x00\x00",
message-format=0, settled=false, more=false] (46) "\x00Sp\xc0\x08\x05BP\x00@@R\x03\x00St\xc1\x14\x04\xa1\x02snR\x01\xa1\x02ts\x81\x14\xa7\xccS\x8fD\x99\x84\x00Sw\xa1\x03one"
> one
> [0x563feb999040]:0 -> @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=0, drain=false]
> [0x563feb999040]:0 -> @disposition(21) [role=true, first=0, last=0, settled=true,
state=@accepted(36) []]

If there are messages in flight when you revoke the credit, they will 
still be delivered from my tests.


Mime
View raw message