Peter Moran created QPID-8538:
---------------------------------
Summary: Receiver fetch method depletes credit and slows down
receiver
Key: QPID-8538
URL: https://issues.apache.org/jira/browse/QPID-8538
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: qpid-cpp-1.39.0
Reporter: Peter Moran
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
# Enables drain mode pn_link_drain(lnk->receiver, 0);
# Tries to process are queued messages (while (pn_link_draining(lnk->receiver)
&& !pn_link_queued(lnk->receiver)))
# 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
# 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
{code:java}
if (lnk->capacity) {
pn_link_flow(lnk->receiver, lnk->capacity - pn_link_credit(lnk->receiver));
{code}
this would much more look like what is inside proton c++ api
{code:java}
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);
{code}
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
