[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613943#comment-16613943
]
ASF GitHub Bot commented on DISPATCH-1081:
------------------------------------------
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/376#discussion_r217501588
--- Diff: docs/books/user-guide/theory_of_operation.adoc ---
@@ -260,26 +260,25 @@ Anycast distribution delivers each message to one
consumer whereas
multicast distribution delivers each message to all consumers.
Anycast delivery is reliable when the message deliveries are
-unsettled. There is a reliability contract that the router network
+unsettled. There is a reliability contract that the router network
abides by when delivering unsettled messages to anycast addresses.
For every such delivery sent by a producer, the router network
guarantees that one of the following outcomes will occur:
-* The delivery shall be settled with ACCEPTED or REJECTED disposition
- where the disposition is supplied by the consumer.
-* The delivery shall be settled with RELEASED disposition, meaning
- that the message was not delivered to any consumer.
-* The delivery shall be settled with MODIFIED disposition, meaning
- that the message may have been delivered to a consumer but should be
- considered in-doubt and re-sent.
-* The connection to the producer shall be dropped, signifying that all
- unsettled deliveries should now be considered in-doubt by the
- producer and later re-sent.
-
-Multicast delivery is not reliable. If a producer sends an unsettled
-delivery, the ingress router shall settle the delivery with ACCEPTED
-disposition regardless of whether the message was delivered to any
-consumers.
+* The delivery shall be settled with ACCEPTED or REJECTED disposition
where the disposition is supplied by the consumer.
+
+* The delivery shall be settled with RELEASED disposition, meaning that
the message was not delivered to any consumer.
+
+* The delivery shall be settled with MODIFIED disposition, meaning that
the message may have been delivered to a consumer but should be considered
in-doubt and re-sent.
+
+* The connection to the producer shall be dropped, signifying that all
unsettled deliveries should now be considered in-doubt by the producer and
later re-sent.
+
+Multicast delivery is not reliable. If a producer sends an unsettled
+delivery, one of the following outcomes will occur:
+
+* If the address has no consumers, the router sends back a disposition of
RELEASED.
+
+* If the address has one or more consumers, the router sends back a
disposition of SETTLED.
--- End diff --
SETTLED is not a disposition. A delivery may be settled or unsettled,
regardless of disposition. The possible dispositions for a delivery are
ACCEPTED, REJECTED, RELEASED, and MODIFIED.
> Messages to multicast addresses are being released when no receivers attached
> -----------------------------------------------------------------------------
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Alexander Rafferty
> Assignee: Ganesh Murthy
> Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
