[ https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987766#comment-16987766 ]
ASF GitHub Bot commented on DISPATCH-1496: ------------------------------------------ ssorj commented on pull request #636: DISPATCH-1496: Reset link variables after the drain is complete. Also… URL: https://github.com/apache/qpid-dispatch/pull/636#discussion_r353703141 ########## File path: include/qpid/dispatch/router_core.h ########## @@ -674,6 +674,15 @@ int qdr_link_process_deliveries(qdr_core_t *core, qdr_link_t *link, int credit); void qdr_link_flow(qdr_core_t *core, qdr_link_t *link, int credit, bool drain_mode); +/** + * The passed in link has been drained, it is no longer in drain mode. Sets the link's drain flag to false and sets credit to core to zero. + * Call this right after calling pn_link_drained + * + * @param core - router core + * @param link - the link that has been drained + */ +void qdr_link_drained(qdr_core_t *core, qdr_link_t *link); Review comment: I know this is the naming Proton has, but it's confusing. 'qdr_link_drained' looks like a predicate. Something like 'qdr_link_mark_drained' or '_set_drained' would be a lot clearer IMO. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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