[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987913#comment-16987913
]
ASF subversion and git services commented on DISPATCH-1496:
-----------------------------------------------------------
Commit 5b8502dcc25b553587e1e0d83c8fe53a4c9b7620 in qpid-dispatch's branch
refs/heads/master from Ganesh Murthy
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=5b8502d ]
DISPATCH-1496 - Additional fix. Renamed qdr_link_drained() to
qdr_link_set_drained()
> router can grant extra credit during drain of a link-routed receiver
> --------------------------------------------------------------------
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 1.9.0
> Reporter: Robbie Gemmell
> Assignee: Ganesh Murthy
> Priority: Major
> Fix For: 1.10.0
>
> Attachments: qdrouterd.conf, simple_recv_drain.py
>
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
