[
https://issues.apache.org/jira/browse/DISPATCH-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated DISPATCH-1481:
---------------------------------
Description:
For all anycast forwarding treatments (balanced, closest, etc.) the router
does not provide capacity (credit) to the publisher until the router is aware
of at least one consumer for that address. This allows the application to
avoid sending messages that the router will simply RELEASE due to lack of
consumers.
This is not the case for multicast producers (specifically, ingress links with
a multicast target address). In fact, the router's behavior has varied over
several releases (both intentionally and unintentionally):
* pre 1.0: mcast credit was consistent with anycast - block until consumers
present
* at 1.0 mcast credit was change to always be provided regardless of the
presence of consumers
([DISPATCH-779|https://issues.apache.org/jira/browse/DISPATCH-779])
* at some point after 1.2 the router began returning RELEASED outcome for
unsettled multicast. This appears to be unintentional (and reveals a hole in
the system test suite) as it can force an infinite loop as credit will
automatically be replenished (per DISPATCH-779).
* in 1.9.0 the router's handling of unsettled multicast outcomes was corrected
and brought in line with the handling of anycast unsettled messages
[DISPATCH-1266|https://issues.apache.org/jira/browse/DISPATCH-1266]. This
change ended up codifying the RELEASED on no-consumer behavior as intentional,
but did not address the infinite credit loop issue.
The router should be consistent in the way it manages credit regardless of the
forwarding treatment. Providing an unlimited credit supply can result in an
infinite transmit->RELEASE->retransmit loop.
was:
For all anycast forwarding treatments (balanced, closest, etc.) the router
does not provide capacity (credit) to the publisher until the router is aware
of at least one consumer for that address. This allows the application to
avoid sending messages that the router will simply RELEASE due to lack of
consumers.
This is not the case for multicast producers (specifically, ingress links with
a multicast target address). In fact, the router's behavior has varied over
several releases (both intentionally and unintentionally):
* pre 1.0: mcast credit was consistent with anycast - block until consumers
present
* at 1.0 mcast credit was change to always be provided regardless of the
presence of consumers
([DISPATCH-779|https://issues.apache.org/jira/browse/DISPATCH-779])
* at some point after 1.2 the router began returning RELEASED outcome for
unsettled multicast. This appears to be unintentional (and reveals a hole in
the system test suite) as it can force an infinite loop as credit will
automatically be replenished (per DISPATCH-779).
* in 1.9.0 the router's handling of unsettled multicast outcomes was corrected
and brought in line with the handling of anycast unsettled messages
[DISPATCH-1266|https://issues.apache.org/jira/browse/DISPATCH-779]. This
change ended up codifying the RELEASED on no-consumer behavior as intentional,
but did not address the infinite credit loop issue.
The router should be consistent in the way it manages credit regardless of the
forwarding treatment. Providing an unlimited credit supply can result in an
infinite transmit->RELEASE->retransmit loop.
> Multicast producers should block on credit until consumers are present
> ----------------------------------------------------------------------
>
> Key: DISPATCH-1481
> URL: https://issues.apache.org/jira/browse/DISPATCH-1481
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
> Affects Versions: 1.8.0, 1.9.0
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Priority: Major
> Fix For: 1.10.0
>
>
> For all anycast forwarding treatments (balanced, closest, etc.) the router
> does not provide capacity (credit) to the publisher until the router is aware
> of at least one consumer for that address. This allows the application to
> avoid sending messages that the router will simply RELEASE due to lack of
> consumers.
> This is not the case for multicast producers (specifically, ingress links
> with a multicast target address). In fact, the router's behavior has varied
> over several releases (both intentionally and unintentionally):
> * pre 1.0: mcast credit was consistent with anycast - block until consumers
> present
> * at 1.0 mcast credit was change to always be provided regardless of the
> presence of consumers
> ([DISPATCH-779|https://issues.apache.org/jira/browse/DISPATCH-779])
> * at some point after 1.2 the router began returning RELEASED outcome for
> unsettled multicast. This appears to be unintentional (and reveals a hole in
> the system test suite) as it can force an infinite loop as credit will
> automatically be replenished (per DISPATCH-779).
> * in 1.9.0 the router's handling of unsettled multicast outcomes was
> corrected and brought in line with the handling of anycast unsettled messages
> [DISPATCH-1266|https://issues.apache.org/jira/browse/DISPATCH-1266]. This
> change ended up codifying the RELEASED on no-consumer behavior as
> intentional, but did not address the infinite credit loop issue.
> The router should be consistent in the way it manages credit regardless of
> the forwarding treatment. Providing an unlimited credit supply can result in
> an infinite transmit->RELEASE->retransmit loop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
