[ 
https://issues.apache.org/jira/browse/DISPATCH-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975146#comment-16975146
 ] 

ASF GitHub Bot commented on DISPATCH-1481:
------------------------------------------

kgiusti 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_r346852200
 
 

 ##########
 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:
   thanks - I've updated the patch with your changes
 
----------------------------------------------------------------
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]

Reply via email to