You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by bh...@apache.org on 2020/04/17 19:48:54 UTC
[qpid-dispatch] branch master updated: DISPATCH-1479 - update
multicast 'accepted' definition. This closes #720.
This is an automated email from the ASF dual-hosted git repository.
bhardesty pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/qpid-dispatch.git
The following commit(s) were added to refs/heads/master by this push:
new bd6f00f DISPATCH-1479 - update multicast 'accepted' definition. This closes #720.
bd6f00f is described below
commit bd6f00f20d2b5fb0c00dddf1fabf527b2f729b69
Author: Ben Hardesty <bh...@redhat.com>
AuthorDate: Thu Apr 16 16:01:03 2020 -0400
DISPATCH-1479 - update multicast 'accepted' definition. This closes #720.
---
docs/books/modules/user-guide/link-routing.adoc | 43 --------
docs/books/modules/user-guide/message-routing.adoc | 112 ---------------------
...age-settlement-reliability-message-routing.adoc | 9 +-
3 files changed, 2 insertions(+), 162 deletions(-)
diff --git a/docs/books/modules/user-guide/link-routing.adoc b/docs/books/modules/user-guide/link-routing.adoc
deleted file mode 100644
index d7fae9f..0000000
--- a/docs/books/modules/user-guide/link-routing.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-// Module included in the following assemblies:
-//
-// routing.adoc
-
-[id='link-routing-{context}']
-= Link routing
-
-Link routing enables you to establish a dedicated, virtual "path" between a sender and receiver that travels through the router network. Link routes are typically used to connect clients to message brokers in scenarios in which a direct connection is unfeasible. Therefore, link routes enable messaging capabilities that are not possible with message routing, such as:
-
-* Transactional messaging
-+
-Link routing supports local transactions to a single broker. Distributed transactions are not supported.
-
-* Guaranteed message delivery order
-+
-Link routing to a sharded queue preserves the delivery order of the producer’s messages by causing all messages on that link to go to the same broker instance.
-
-* End-to-end flow control
-+
-Flow control is "real" in that credits flow across the link route from the receiver to the sender.
-
-* Server-side selectors
-+
-With a link route, consumers can provide server-side selectors for broker subscriptions.
\ No newline at end of file
diff --git a/docs/books/modules/user-guide/message-routing.adoc b/docs/books/modules/user-guide/message-routing.adoc
deleted file mode 100644
index 6aa9df9..0000000
--- a/docs/books/modules/user-guide/message-routing.adoc
+++ /dev/null
@@ -1,112 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-// Module included in the following assemblies:
-//
-// routing.adoc
-
-[id='message-routing-{context}']
-= Message routing
-
-Message routing enables you to distribute messages in anycast and multicast patterns. These patterns can be used for both direct routing, in which the router distributes messages between clients without a message broker, and indirect routing, in which the router enables clients to exchange messages through a message broker.
-
-With message routing, messages are routed based on their _addresses_, and the _routing pattern_ defined for the address.
-
-[discrete]
-== Addresses
-
-An _address_ is the name of a message source or destination endpoint in the messaging network. AMQP addresses control the flow of messages across the router network.
-
-Addresses can designate various types of entities in a messaging network, such as:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a message broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-When a router receives a message, it uses the message’s address to determine where to send the message (either its destination or one step closer to its destination).
-
-[NOTE]
-====
-{RouterName} treats addresses as opaque strings. Therefore, when creating addresses, you can use whatever syntax makes the most sense for your environment.
-====
-
-[discrete]
-== What mobile addresses are
-
-Addresses used in message routing are sometimes called _mobile addresses_, because ...
-
-[discrete]
-== Routing patterns
-
-Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.
-
-{RouterName} supports two categories of routing patterns: anycast and multicast.
-
-[NOTE]
-====
-{RouterName} does not provide a true "unicast" routing pattern in which there is only one consumer for an address.
-====
-
-[options="header"]
-|===
-| Routing pattern | Description | Reliability
-
-| Anycast
-a| Each message is delivered to one consumer. There are two types of anycast methods:
-
-* Balanced
-+
-Each message is delivered to a single consumer only, and {RouterName} attempts to balance the traffic load across the router network. This method allows multiple consumers to use the same address.
-
-* Closest
-+
-Each message is sent along the shortest path to reach the destination, even if there are other consumers for the same address.
-
-| Reliable for unsettled message deliveries.
-
-| Multicast
-| Each message is delivered to all consumers. Each consumer will receive one copy of the message.
-| Unreliable. If a producer sends an unsettled delivery, the router automatically settles the delivery with ACCEPTED disposition regardless of whether the message was delivered to any consumers.
-
-|===
-
-[discrete]
-== Quality of service for message deliveries
-
-{RouterName} can deliver messages with any of the following levels of reliability:
-
-* At most once
-* At least once
-* Exactly once
-
-The level of reliability is negotiated between the client and router when the client establishes a link to the router. The router achieves this negotiated level of reliability by treating messages as either _pre-settled_ or _unsettled_.
-
-Pre-settled::
-Sometimes called "fire and forget", the router settles the incoming and outgoing deliveries and propagates the settlement to the message’s destination. However, it does not guarantee delivery.
-
-Unsettled::
-The router propagates the settlement between the producer and consumer, and guarantees one of the following outcomes:
-+
-* The delivery is settled with ACCEPTED or REJECTED disposition where the disposition is supplied by the consumer.
-* The delivery is settled with RELEASED disposition, meaning that the message was not delivered to any consumer.
-* The delivery is 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 is dropped, signifying that all unsettled deliveries should now be considered in-doubt by the producer and re-sent.
diff --git a/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc b/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc
index f78b3d5..9acf789 100644
--- a/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc
+++ b/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc
@@ -47,13 +47,8 @@ The following table describes the reliability guarantees for unsettled messages
| Final disposition | Anycast | Multicast
| `accepted`
-| The consumer received the message.
-a|
-Either:
-
-* All consumers received the message,
-
-* Or, at least one consumer received the message, but no consumers rejected it.
+| The consumer accepted the message.
+| At least one consumer accepted the message, but no consumers rejected it.
| `released`
| The message did not reach its destination.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org