[
https://issues.apache.org/jira/browse/QPID-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Moran updated QPID-8538:
------------------------------
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
# Enables drain mode pn_link_drain(lnk->receiver, 0);
# Tries to process all 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.
was:
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.
> 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
> Priority: Major
>
> 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 all 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]
