You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by tr...@apache.org on 2016/04/04 19:05:26 UTC
qpid-dispatch git commit: DISPATCH-256 - Updates to the documentation
Repository: qpid-dispatch
Updated Branches:
refs/heads/master 7817e2b87 -> 043dd2d62
DISPATCH-256 - Updates to the documentation
Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/043dd2d6
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/043dd2d6
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/043dd2d6
Branch: refs/heads/master
Commit: 043dd2d62073cb146d2b6e48c061eee38193a52f
Parents: 7817e2b
Author: Ted Ross <tr...@redhat.com>
Authored: Mon Apr 4 13:02:02 2016 -0400
Committer: Ted Ross <tr...@redhat.com>
Committed: Mon Apr 4 13:02:02 2016 -0400
----------------------------------------------------------------------
doc/book/amqp-mapping.rst | 72 +++---
doc/book/auto_links.rst | 251 +++++++++++++++++++++
doc/book/basic_usage.rst | 54 +++--
doc/book/link_routing.rst | 46 ++--
doc/book/tools.rst | 38 ++--
doc/book/using.rst | 1 +
python/qpid_dispatch/management/qdrouter.json | 2 +-
7 files changed, 373 insertions(+), 91 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/amqp-mapping.rst
----------------------------------------------------------------------
diff --git a/doc/book/amqp-mapping.rst b/doc/book/amqp-mapping.rst
index 2287c6b..465acd9 100644
--- a/doc/book/amqp-mapping.rst
+++ b/doc/book/amqp-mapping.rst
@@ -58,9 +58,9 @@ The following Message Annotation fields are defined by Dispatch Router:
| | | |
| | | |
+--------------------+------------------+-------------------------------------------------------+
-| x-opt-qd.class | string |Message class. This is used to allow the router to |
-| | |provide separate paths for different classes of |
-| | |traffic. |
+| x-opt-qd.phase | integer |The address-phase, if not zero, for messages flowing |
+| | |between routers. |
+| | | |
+--------------------+------------------+-------------------------------------------------------+
Source/Target Capabilities
@@ -72,8 +72,12 @@ The following Capability values are used in Sources and Targets.
| *Capability* | *Description* |
+================+============================================================================+
| qd.router |This capability is added to sources and targets that are used for |
-| |inter-router message exchange. |
-| | |
+| |inter-router message exchange. This capability denotes a link used for |
+| |router-control messages flowing between routers. |
++----------------+----------------------------------------------------------------------------+
+| qd.router-data |This capability is added to sources and targets that are used for |
+| |inter-router message exchange. This capability denotes a link used for |
+| |user messages being message-routed across an inter-router connection. |
+----------------+----------------------------------------------------------------------------+
Dynamic-Node-Properties
@@ -113,7 +117,7 @@ Address Patterns
| | |
| | |
+--------------------------------+-------------------------------------------------------+
-| `_topo/<area>/<router>/<addr>` |An address that references an endpoint attached to a |
+| `_topo/0/<router>/<addr>` |An address that references an endpoint attached to a |
| |specific router node in the network topology. Messages |
| |with addresses that follow this pattern shall be routed|
| |along the shortest path to the specified router. Note |
@@ -121,9 +125,9 @@ Address Patterns
| |that the address itself contains enough information to |
| |route the message to its destination. |
| | |
-| | |
-| | |
-| | |
+| |The '0' component immediately preceding the router-id |
+| |is a placeholder for an _area_ which may be used in |
+| |the future if area routing is implemented. |
| | |
| | |
| | |
@@ -161,31 +165,31 @@ Address Patterns
Supported Addresses
~~~~~~~~~~~~~~~~~~~
-+------------------------------+------------------------------------------------------------+
-| *Address* | *Description* |
-+==============================+============================================================+
-| `$management` |The management agent on the attached router/container. This |
-| |address would be used by an endpoint that is a management |
-| |client/console/tool wishing to access management data from |
-| |the attached container. |
-+------------------------------+------------------------------------------------------------+
-| `_topo/0/Router.E/agent` |The management agent at Router.E in area 0. This address |
-| |would be used by a management client wishing to access |
-| |management data from a specific container that is reachable |
-| |within the network. |
-+------------------------------+------------------------------------------------------------+
-| `_local/qdhello` |The router entity in each of the connected routers. This |
-| |address is used to communicate with neighbor routers and is |
-| |exclusively for the HELLO discovery protocol. |
-+------------------------------+------------------------------------------------------------+
-| `_local/qdrouter` |The router entity in each of the connected routers. This |
-| |address is used by a router to communicate with other |
-| |routers in the network. |
-+------------------------------+------------------------------------------------------------+
-| `_topo/0/Router.E/qdrouter` |The router entity at the specifically indicated router. This|
-| |address form is used by a router to communicate with a |
-| |specific router that may or may not be a neighbor. |
-+------------------------------+------------------------------------------------------------+
++---------------------------------+------------------------------------------------------------+
+| *Address* | *Description* |
++=================================+============================================================+
+| `$management` |The management agent on the attached router/container. This |
+| |address would be used by an endpoint that is a management |
+| |client/console/tool wishing to access management data from |
+| |the attached container. |
++---------------------------------+------------------------------------------------------------+
+| `_topo/0/Router.E/$management` |The management agent at Router.E in area 0. This address |
+| |would be used by a management client wishing to access |
+| |management data from a specific container that is reachable |
+| |within the network. |
++---------------------------------+------------------------------------------------------------+
+| `_local/qdhello` |The router entity in each of the connected routers. This |
+| |address is used to communicate with neighbor routers and is |
+| |exclusively for the HELLO discovery protocol. |
++---------------------------------+------------------------------------------------------------+
+| `_local/qdrouter` |The router entity in each of the connected routers. This |
+| |address is used by a router to communicate with other |
+| |routers in the network. |
++---------------------------------+------------------------------------------------------------+
+| `_topo/0/Router.E/qdrouter` |The router entity at the specifically indicated router. This|
+| |address form is used by a router to communicate with a |
+| |specific router that may or may not be a neighbor. |
++---------------------------------+------------------------------------------------------------+
Implementation of the AMQP Management Specification
---------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/auto_links.rst
----------------------------------------------------------------------
diff --git a/doc/book/auto_links.rst b/doc/book/auto_links.rst
new file mode 100644
index 0000000..52e4b19
--- /dev/null
+++ b/doc/book/auto_links.rst
@@ -0,0 +1,251 @@
+.. 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.
+
+Indirect Waypoints and Auto-Links
+=================================
+
+This feature was introduced in Qpid Dispatch 0.6. It is a significant
+improvement on an earlier somewhat experimental feature called
+Waypoints.
+
+Auto-link is a feature of Qpid Dispatch Router that enables a router
+to actively attach a link to a node on an external AMQP container.
+The obvious application for this feature is to route messages through
+a queue on a broker, but other applications are possible as well.
+
+An auto-link manages the lifecycle of one AMQP link. If messages are
+to be routed to and from a queue on a broker, then two auto-links are
+needed: one for sending messages to the queue and another for
+receiving messages from the queue. The container to which an
+auto-link attempts to attach may be identified in one of two ways:
+
+ - The name of the connector/listener that resulted in the connection
+ of the container, or
+ - The AMQP container-id of the remote container.
+
+Queue Waypoint Example
+----------------------
+
+Here is an example configuration for routing messages deliveries
+through a pair of queues on a broker:
+
+::
+
+ connector {
+ name: broker
+ role: route-container
+ addr: <hostname>
+ port: <port>
+ sasl-mechanisms: ANONYMOUS
+ }
+
+ address {
+ prefix: queue
+ waypoint: yes
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: in
+ connection: broker
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: out
+ connection: broker
+ }
+
+ autoLink {
+ addr: queue.second
+ dir: in
+ connection: broker
+ }
+
+ autoLink {
+ addr: queue.second
+ dir: out
+ connection: broker
+ }
+
+The *address* entity identifies a namespace (queue.*) that will be
+used for routing messages through queues via autolinks. The four
+*autoLink* entities identify the head and tail of two queues on the
+broker that will be connected via auto-links.
+
+If there is no broker connected, the auto-links shall remain
+*inactive*. This can be observed by using the *qdstat* tool:
+
+::
+
+ $ qdstat --autolinks
+ AutoLinks
+ addr dir phase link status lastErr
+ ===================================================
+ queue.first in 1 inactive
+ queue.first out 0 inactive
+ queue.second in 1 inactive
+ queue.second out 0 inactive
+
+If a broker comes online with a queue called *queue.first*, the
+auto-links will attempt to activate:
+
+::
+
+ $ qdstat --autolinks
+ AutoLinks
+ addr dir phase link status lastErr
+ ======================================================================
+ queue.first in 1 6 active
+ queue.first out 0 7 active
+ queue.second in 1 failed Node not found: queue.second
+ queue.second out 0 failed Node not found: queue.second
+
+Note that two of the auto-links are in *failed* state because the
+queue does not exist on the broker.
+
+If we now use the Qpid Proton example application *simple_send* to
+send three messages to queue.first via the router:
+
+::
+
+ $ python simple_send.py -a 127.0.0.1/queue.first -m3
+ all messages confirmed
+
+and then look at the address statistics on the router:
+
+::
+
+ $ qdstat -a
+ Router Addresses
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ========================================================================================================
+ mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
+ mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
+
+we see that *queue.first* appears twice in the list of addresses. The
+*phs*, or phase column shows that there are two phases for the
+address. Phase '0' is for routing message deliveries from producers
+to the tail of the queue (the *out* auto-link associated with the
+queue). Phase '1' is for routing deliveries from the head of the
+queue to subscribed consumers.
+
+Note that three deliveries have been counted in the "in" and "out"
+columns for phase '0'. The "in" column represents the three messages
+that arrived from simple_send and the "out" column represents the
+three deliveries to the queue on the broker.
+
+If we now use *simple_recv* to receive three messages from this
+address:
+
+::
+
+ $ python simple_recv_noignore.py -a 127.0.0.1:5672/queue.first -m3
+ {u'sequence': int32(1)}
+ {u'sequence': int32(2)}
+ {u'sequence': int32(3)}
+
+We receive the three queued messages. Looking at the addresses again,
+we see that phase '1' was used to deliver those messages from the
+queue to the consumer.
+
+::
+
+ $ qdstat -a
+ Router Addresses
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ========================================================================================================
+ mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
+ mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
+
+Note that even in a multi-router network, and with multiple producers
+and consumers for *queue.first*, all deliveries will be routed through
+the queue on the connected broker.
+
+Sharded Queue Example
+---------------------
+
+Here is an extension of the above example to illustrate how Qpid
+Dispatch Router can be used to create a distributed queue in which
+multiple brokers share the message-queueing load.
+
+::
+
+ connector {
+ name: broker1
+ role: route-container
+ addr: <hostname>
+ port: <port>
+ sasl-mechanisms: ANONYMOUS
+ }
+
+ connector {
+ name: broker2
+ role: route-container
+ addr: <hostname>
+ port: <port>
+ sasl-mechanisms: ANONYMOUS
+ }
+
+ address {
+ prefix: queue
+ waypoint: yes
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: in
+ connection: broker1
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: out
+ connection: broker1
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: in
+ connection: broker2
+ }
+
+ autoLink {
+ addr: queue.first
+ dir: out
+ connection: broker2
+ }
+
+In the above configuration, there are two instances of *queue.first*
+on brokers 1 and 2. Message traffic from producers to address
+*queue.first* shall be balanced between the two instance and messages
+from the queues shall be balanced across the collection of subscribers
+to the same address.
+
+Dynamically Adding Shards
+-------------------------
+
+Since configurable entities in the router can also be accessed via the
+management protocol, we can remotely add a shard to the above example
+using *qdmanage*:
+
+::
+
+ qdmanage create --type org.apache.qpid.dispatch.connector addr=<host> port=<port> name=broker3
+ qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
+ qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3
+
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/basic_usage.rst
----------------------------------------------------------------------
diff --git a/doc/book/basic_usage.rst b/doc/book/basic_usage.rst
index 5f755b3..232991a 100644
--- a/doc/book/basic_usage.rst
+++ b/doc/book/basic_usage.rst
@@ -34,14 +34,17 @@ like the following:
$ qdstat -a
Router Addresses
- class address phase in-proc local remote in out thru to-proc from-proc
- ===========================================================================================
- local $management Y 0 0 0 0 0 0 0
- mobile $management 0 Y 0 0 1 0 0 1 0
- local temp.4Q3i01lWbs 1 0 0 0 0 0 0
-
-Note that there are two known addresses. *$management* is the address of
-the router's embedded management agent. *temp.4Q3i01lWbs* is the temporary
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ===============================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 1 0 0 1 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ local temp.1GThUllfR7N+BDP closest 0 1 0 0 0 0 0 0 0
+
+
+Note that there are a number of known addresses. *$management* is the address of
+the router's embedded management agent. *temp.1GThUllfR7N+BDP* is the temporary
reply-to address of the *qdstat* client making requests to the agent.
If you change the mode to interior and restart the processs, the same
@@ -52,14 +55,19 @@ inter-router communication:
$ qdstat -a
Router Addresses
- class address phase in-proc local remote in out thru to-proc from-proc
- ===========================================================================================
- local $management Y 0 0 0 0 0 0 0
- mobile $management 0 Y 0 0 1 0 0 1 0
- local qdhello Y 0 0 0 0 0 0 3
- local qdrouter Y 0 0 0 0 0 0 1
- local qdrouter.ma Y 0 0 0 0 0 0 0
- local temp.2ot2AWsnYz 1 0 0 0 0 0 0
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ =================================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 1 0 0 1 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ local qdhello flood 1 0 0 0 0 0 0 0 10
+ local qdrouter flood 1 0 0 0 0 0 0 0 0
+ topo qdrouter flood 1 0 0 0 0 0 0 0 1
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 0 0
+ topo qdrouter.ma multicast 1 0 0 0 0 0 0 0 0
+ local temp.wfx54+zf+YWQF3T closest 0 1 0 0 0 0 0 0 0
+
Mobile Subscribers
------------------
@@ -84,12 +92,14 @@ address. To verify the subscription:
$ qdstat -a
Router Addresses
- class address phase in-proc local remote in out thru to-proc from-proc
- ===========================================================================================
- local $management Y 0 0 0 0 0 0 0
- mobile $management 0 Y 0 0 1 0 0 1 0
- mobile my-address 0 1 0 0 0 0 0 0
- local temp.JAgKj1+iB8 1 0 0 0 0 0 0
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ===============================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 2 0 0 2 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ mobile my-address 0 closest 0 1 0 0 0 0 0 0 0
+ local temp.75_d2X23x_KOT51 closest 0 1 0 0 0 0 0 0 0
You can then, in a separate command window, run a sender to produce
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/link_routing.rst
----------------------------------------------------------------------
diff --git a/doc/book/link_routing.rst b/doc/book/link_routing.rst
index b7e3d75..7f65a4a 100644
--- a/doc/book/link_routing.rst
+++ b/doc/book/link_routing.rst
@@ -19,6 +19,7 @@ Link Routing
============
This feature was introduced in Qpid Dispatch 0.4.
+This feature was significantly updated in Qpid Dispatch 0.6.
Link-routing is an alternative strategy for routing messages across a
network of routers. With the existing message-routing strategy, each
@@ -34,7 +35,9 @@ The main benefit to link-routing is that endpoints can use the full link
protocol to interact with other endpoints in far-flung parts of the
network. For example, a client can establish a receiver across the
network to a queue on a remote broker and use link credit to control
-the flow of messages from the broker.
+the flow of messages from the broker. Similarly, a receiver can
+establish a link to a topic on a remote broker using a server-side
+filter.
Why would one want to do this? One reason is to provide client
isolation. A network like the following can be deployed:
@@ -93,13 +96,13 @@ broker B2:
connector {
name: broker
- role: on-demand
+ role: route-container
addr: <B2-url>
port: <B2-port>
sasl-mechanisms: ANONYMOUS
}
-This *on-demand* connector tells the router how to connect to an
+This *route-container* connector tells the router how to connect to an
external AMQP container when it is needed. The name "broker" will be
used later to refer to this connection.
@@ -107,36 +110,45 @@ Now, the router must be configured to route certain addresses to B2:
::
- linkRoutePattern {
+ linkRoute {
prefix: b2
- connector: broker
+ dir: in
+ connection: broker
+ }
+
+ linkRoute {
+ prefix: b2
+ dir: out
+ connection: broker
}
-The linkRoutePattern tells router Ra that any sender or receiver that
+The linkRoute tells router Ra that any sender or receiver that
is attached with a target or source (respectively) whos address begins
-with "b2", should be routed to the broker B2 (via the on-demand
+with "b2", should be routed to the broker B2 (via the route-container
connector).
+Note that receiving and sending links are configured and routed
+separately. This allows configuration of link routes for listeners
+only or senders only. A direction of "in" matches client senders
+(i.e. links that carry messages inbound to the router network).
+Direction "out" matches client receivers.
+
Examples of addresses that "begin with 'b2'" include:
- b2
- - b2/queues
- - b2/queues/app1
+ - b2.queues
+ - b2.queues.app1
-When the on-demand connector is configured, router Ra establishes a
+When the route-container connector is configured, router Ra establishes a
connection to the broker. Once the connection is open, Ra tells the
other routers (Rp and Rb) that it is a valid destination for
link-routes to the "b2" prefix. This means that sender or receiver
links attached to Rb or Rp will be routed via the shortest path to Ra
where they are then routed outbound to the broker B2.
-On Rp and Rb, it is advisable to add the following configuration:
-
-::
-
- linkRoutePattern {
- prefix: b2
- }
+On Rp and Rb, it is advisable to add the identical configuration. It
+is permissible for a linkRoute configuration to reference a connection
+that does not exist.
This configuration tells the routers that link-routing is intended to
be available for targets and sources starting with "b2". This is
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/tools.rst
----------------------------------------------------------------------
diff --git a/doc/book/tools.rst b/doc/book/tools.rst
index f5e545b..a31757f 100644
--- a/doc/book/tools.rst
+++ b/doc/book/tools.rst
@@ -22,25 +22,29 @@ qdstat
------
*qdstat* is a command line tool that lets you view the status of a
-Dispatch Router. The following options are useful for seeing that the
+Dispatch Router. The following options are useful for seeing what the
router is doing:
-+----------+-----------------------------------------------------------------------------+
-| *Option* | *Description* |
-+==========+=============================================================================+
-| -l |Print a list of AMQP links attached to the router. Links are |
-| |unidirectional. Outgoing links are usually associated with a subscription |
-| |address. The tool distinguishes between *endpoint* links and *router* |
-| |links. Endpoint links are attached to clients using the router. Router links |
-| |are attached to other routers in a network of routbers. |
-| | |
-+----------+-----------------------------------------------------------------------------+
-| -a |Print a list of addresses known to the router. |
-+----------+-----------------------------------------------------------------------------+
-| -n |Print a list of known routers in the network. |
-+----------+-----------------------------------------------------------------------------+
-| -c |Print a list of connections to the router. |
-+----------+-----------------------------------------------------------------------------+
++--------------+-----------------------------------------------------------------------------+
+| *Option* | *Description* |
++==============+=============================================================================+
+| -l |Print a list of AMQP links attached to the router. Links are |
+| |unidirectional. Outgoing links are usually associated with a subscription |
+| |address. The tool distinguishes between *endpoint* links and *router* |
+| |links. Endpoint links are attached to clients using the router. Router links |
+| |are attached to other routers in a network of routbers. |
+| | |
++--------------+-----------------------------------------------------------------------------+
+| -a |Print a list of addresses known to the router. |
++--------------+-----------------------------------------------------------------------------+
+| -n |Print a list of known routers in the network. |
++--------------+-----------------------------------------------------------------------------+
+| -c |Print a list of connections to the router. |
++--------------+-----------------------------------------------------------------------------+
+| --autolinks |Print a list of configured auto-links. |
++--------------+-----------------------------------------------------------------------------+
+| --linkroutes |Print a list of configures link-routes. |
++--------------+-----------------------------------------------------------------------------+
For complete details see the `qdstat(8)` man page and the output of
`qdstat --help`.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/doc/book/using.rst
----------------------------------------------------------------------
diff --git a/doc/book/using.rst b/doc/book/using.rst
index a438492..474758d 100644
--- a/doc/book/using.rst
+++ b/doc/book/using.rst
@@ -25,5 +25,6 @@ Using Qpid Dispatch
tools
basic_usage
link_routing
+ auto_links
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/043dd2d6/python/qpid_dispatch/management/qdrouter.json
----------------------------------------------------------------------
diff --git a/python/qpid_dispatch/management/qdrouter.json b/python/qpid_dispatch/management/qdrouter.json
index 48a735e..371d23a 100644
--- a/python/qpid_dispatch/management/qdrouter.json
+++ b/python/qpid_dispatch/management/qdrouter.json
@@ -961,7 +961,7 @@
"attributes": {
"addr": {
"type": "string",
- "description": "The address or address prefix for the provisioned object",
+ "description": "The address of the provisioned object",
"create": true,
"required": true
},
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org