[
https://issues.apache.org/jira/browse/DISPATCH-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16974510#comment-16974510
]
ASF GitHub Bot commented on DISPATCH-1481:
------------------------------------------
bhardesty commented on pull request #618: DISPATCH-1481: Multicast links should
block until a consumer is present
URL: https://github.com/apache/qpid-dispatch/pull/618#discussion_r346471860
##########
File path: docs/books/modules/user-guide/routing.adoc
##########
@@ -116,6 +116,10 @@ This involves configuring an address with a routing
pattern. All messages sent t
+
This involves configuring a waypoint address to identify the broker queue and
then connecting the router to the broker. All messages sent to the waypoint
address will be routed to the broker queue.
+=== Sending Messages to {RouterName}
+
+{RouterName} moves messages directly from publishers to consumers. The router
does not provide message storage as would a broker. A message sent to the
router must have at least one consumer present in order to properly route the
message. The router uses a _credit_ based flow control mechanism to prevent
publishers from passing messages to the router when there are no consumers
present. A client wishing to publish a message to the router must wait until
the router has provided it with credit. Attempting to publish a message
without credit available will cause the client to block. Once credit is made
available the client will unblock and the message will be sent to the router.
Most AMQP client libraries provide a means for determining the amount of credit
available to a publisher.
+
=== Addresses
Review comment:
Took a stab at revising this:
=== Message Routing Flow Control
{RouterName} uses a \_credit-based\_ flow control mechanism to ensure that
producers can only send messages to a router if at least one consumer is
available to receive them. Because {RouterName} does not store messages, this
credit-based flow control prevents producers from sending messages when there
are no consumers present.
A client wishing to send a message to the router must wait until the router
has provided it with credit. Attempting to publish a message without credit
available will cause the client to block. Once credit is made available, the
client will unblock, and the message will be sent to the router.
NOTE: Most AMQP client libraries enable you to determine the amount of
credit available to a producer. For more information, consult your client's
documentation.
----------------------------------------------------------------
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:
[email protected]
> 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]
