[QPID-8538] Receiver fetch method depletes credit and slows down receiver

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: qpid-cpp-1.39.0
• Component/s: C++ Client
• Assignee: Unassigned
• Reporter: Peter Moran
• Created: 09/Jun/21 12:17
• Updated: 10/Jun/21 13:31

Description

As remote broker java broker is used.

e.g
capacity of link is 10
credit is 10

When calling Method ConnectionContext::fetch and there are no data available inside receiver (get returns false) it

1. Enables drain mode  pn_link_drain(lnk->receiver, 0);
2. Tries to process all queued messages (while (pn_link_draining(lnk->receiver) && !pn_link_queued(lnk->receiver)))
3. Credit is being drained by broker pn_do_flow in proton ( pn_sequence_t delta = delivery_count - link->state.delivery_count -> delta is 10 and credit is cleared to 0, yet no messages arrived from broker at all
   if there are queued messages and credit is 0 then pn_link_draining returns false and while stops
4. however if (lnk->capacity && pn_link_queued(lnk->receiver) == 0) replenish credit only if there are no outstanding queued messages to the maximum capacity, this should be rather capacity - credit, but also the condition seems to be wrong, it should not check the queued messages.

the code should look like this

if (lnk->capacity) {
    pn_link_flow(lnk->receiver, lnk->capacity - pn_link_credit(lnk->receiver));
}

or

if (lnk->capacity) { 
pn_link_flow(lnk->receiver, pn_link_drained(lnk->receiver));
}

this would much more look like what is inside proton c++ api

void credit_topup(pn_link_t *link) {
    assert(pn_link_is_receiver(link));
    int window = link_context::get(link).credit_window;
    if (window) {
        int delta = window - pn_link_credit(link);
        pn_link_flow(link, delta);
    }
}
      // receiver
            if (!pn_link_credit(lnk) && lctx.draining) {
                lctx.draining = false;
                pn_link_set_drain(lnk, false);
                receiver r(make_wrapper<receiver>(lnk));
                handler.on_receiver_drain_finish(r);
            }
            credit_topup(lnk);

there is no condition about queued and also the resulting credit is set to the link capacity
(e.g 10 - delta) delta is delivery count reduced from by pn_do_flow,

However this to me looks like some incompatibility between client and broker, as one would not expect that delta is 10 if no messages are received from broker. is this some kind of message sequencing problem?

 

fyi pn_link_queued messages does not mean they they are locally available they might be still on broker and also getAvaialable implementation is wrong.