From 9c73ef7a5ac10acd6a50d5d52bd721fc2faa5919 Mon Sep 17 00:00:00 2001 From: Kim van der Riet Date: Thu, 28 Feb 2013 16:14:30 +0000 Subject: Update from trunk r1375509 through r1450773 git-svn-id: https://svn.apache.org/repos/asf/qpid/branches/asyncstore@1451244 13f79535-47bb-0310-9956-ffa450edef68 --- doc/book/src/Makefile.inc | 2 +- .../cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml | 1 - doc/book/src/cpp-broker/Active-Active-Cluster.xml | 561 -- doc/book/src/cpp-broker/Active-Passive-Cluster.xml | 236 +- doc/book/src/cpp-broker/Security.xml | 979 ++- .../AMQP-Messaging-Broker-Java-Book.xml | 71 +- doc/book/src/java-broker/Add-New-Users.xml | 237 - .../src/java-broker/Broker-Configuration-Guide.xml | 28 - doc/book/src/java-broker/Configure-ACLs.xml | 441 -- ...Configure-Java-Qpid-to-use-a-SSL-connection.xml | 84 - .../Configure-Log4j-CompositeRolling-Appender.xml | 150 - .../Configure-the-Broker-via-config.xml.xml | 71 - ...gure-the-Virtual-Hosts-via-virtualhosts.xml.xml | 131 - .../java-broker/Configuring-Management-Users.xml | 117 - .../Configuring-Qpid-JMX-Management-Console.xml | 181 - doc/book/src/java-broker/Debug-using-log4j.xml | 298 - doc/book/src/java-broker/HA-Guide.xml | 1008 --- .../How-to-Tune-M3-Java-Broker-Performance.xml | 172 - .../How-to-Use-SlowConsumerDisconnect.xml | 280 - ...va-Broker-Concepts-Authentication-Providers.xml | 26 + .../java-broker/Java-Broker-Concepts-Exchanges.xml | 26 + .../Java-Broker-Concepts-Other-Services.xml | 26 + .../src/java-broker/Java-Broker-Concepts-Ports.xml | 26 + .../java-broker/Java-Broker-Concepts-Protocols.xml | 26 + .../java-broker/Java-Broker-Concepts-Queues.xml | 26 + .../Java-Broker-Concepts-Virtual-Hosts.xml | 26 + doc/book/src/java-broker/Java-Broker-Concepts.xml | 32 + ...roker-Configuring-And-Managing-Config-Files.xml | 178 + .../Java-Broker-Configuring-And-Managing-JMX.xml | 26 + ...oker-Configuring-And-Managing-Other-Tooling.xml | 26 + ...va-Broker-Configuring-And-Managing-REST-API.xml | 263 + ...Broker-Configuring-And-Managing-Web-Console.xml | 35 + .../Java-Broker-Configuring-And-Managing.xml | 30 + .../Java-Broker-Exchanges-Binding-Arguments.xml | 26 + doc/book/src/java-broker/Java-Broker-Exchanges.xml | 26 + .../src/java-broker/Java-Broker-Feature-Guide.xml | 84 - .../java-broker/Java-Broker-Getting-Started.xml | 140 + .../java-broker/Java-Broker-High-Availability.xml | 1005 +++ .../src/java-broker/Java-Broker-Installation.xml | 185 + .../src/java-broker/Java-Broker-Introduction.xml | 89 + .../src/java-broker/Java-Broker-Miscellaneous.xml | 80 + .../Java-Broker-Queues-Messaging-Groups.xml | 26 + .../java-broker/Java-Broker-Queues-OtherTypes.xml | 276 + doc/book/src/java-broker/Java-Broker-Queues.xml | 27 + .../src/java-broker/Java-Broker-Runtime-Alerts.xml | 26 + ...Disk-Space-Management-Producer-Flow-Control.xml | 228 + .../Java-Broker-Runtime-Disk-Space-Management.xml | 27 + ...ker-Runtime-Handling-Undeliverable-Messages.xml | 169 + .../java-broker/Java-Broker-Runtime-Log-Files.xml | 26 + ...Broker-Runtime-Producer-Transaction-Timeout.xml | 181 + doc/book/src/java-broker/Java-Broker-Runtime.xml | 30 + .../src/java-broker/Java-Broker-Security-ACLs.xml | 536 ++ ...va-Broker-Security-Authentication-Providers.xml | 320 + .../Java-Broker-Security-Group-Providers.xml | 73 + .../src/java-broker/Java-Broker-Security-SSL.xml | 119 + .../Java-Broker-Security-Users-And-Groups.xml | 26 + doc/book/src/java-broker/Java-Broker-Security.xml | 30 + .../java-broker/Java-Broker-Stores-BDB-Store.xml | 94 + .../java-broker/Java-Broker-Stores-Derby-Store.xml | 56 + .../Java-Broker-Stores-HA-BDB-Store.xml | 62 + .../Java-Broker-Stores-Memory-Store.xml | 61 + .../java-broker/Java-Broker-Stores-SQL-Store.xml | 26 + doc/book/src/java-broker/Java-Broker-Stores.xml | 30 + .../src/java-broker/Java-Broker-Virtual-Hosts.xml | 25 + .../src/java-broker/Java-Environment-Variables.xml | 84 - .../java-broker/Management-Console-Security.xml | 251 - doc/book/src/java-broker/OtherQueueTypes.xml | 274 - doc/book/src/java-broker/Producer-Flow-Control.xml | 217 - .../Qpid-JMX-Management-Console-FAQ.xml | 96 - .../Qpid-JMX-Management-Console-User-Guide.xml | 793 --- .../java-broker/Qpid-JMX-Management-Console.xml | 53 - .../Qpid-Java-Broker-Management-CLI.xml | 159 - .../src/java-broker/Qpid-Java-Build-How-To.xml | 365 -- doc/book/src/java-broker/Qpid-Java-FAQ.xml | 890 --- .../src/java-broker/Qpid-Management-Features.xml | 185 - .../src/java-broker/Qpid-Troubleshooting-Guide.xml | 156 - doc/book/src/java-broker/Topic-Configuration.xml | 107 - doc/book/src/java-broker/commonEntities.xml | 39 + doc/book/src/java-broker/images/3113098.png | Bin 9805 -> 0 bytes doc/book/src/java-broker/images/3113099.png | Bin 12882 -> 0 bytes doc/book/src/java-broker/images/3113100.png | Bin 38529 -> 0 bytes doc/book/src/java-broker/images/3113101.png | Bin 45933 -> 0 bytes doc/book/src/java-broker/images/3113102.png | Bin 7126 -> 0 bytes doc/book/src/java-broker/images/3113103.png | Bin 34693 -> 0 bytes doc/book/src/java-broker/images/3113104.png | Bin 61810 -> 0 bytes doc/book/src/java-broker/images/3113105.png | Bin 26365 -> 0 bytes doc/book/src/java-broker/images/3113106.png | Bin 45911 -> 0 bytes doc/book/src/java-broker/images/3113107.png | Bin 31789 -> 0 bytes doc/book/src/java-broker/images/3113108.png | Bin 39198 -> 0 bytes doc/book/src/java-broker/images/3113109.png | Bin 13295 -> 0 bytes doc/book/src/java-broker/images/3113110.png | Bin 38715 -> 0 bytes doc/book/src/java-broker/images/3113111.png | Bin 52694 -> 0 bytes doc/book/src/java-broker/images/3113112.png | Bin 39276 -> 0 bytes doc/book/src/java-broker/images/3113113.png | Bin 46459 -> 0 bytes doc/book/src/java-broker/images/3113114.png | Bin 64661 -> 0 bytes doc/book/src/java-broker/images/3113115.png | Bin 38902 -> 0 bytes doc/book/src/java-broker/images/3113116.png | Bin 9252 -> 0 bytes doc/book/src/java-broker/images/3113117.png | Bin 40855 -> 0 bytes doc/book/src/java-broker/images/3113118.png | Bin 13796 -> 0 bytes doc/book/src/java-broker/images/3113119.png | Bin 39115 -> 0 bytes .../images/HA-BDBHAMessageStore-MBean-jconsole.png | Bin 52500 -> 52533 bytes .../java-broker/images/Management-Web-Console.png | Bin 0 -> 62590 bytes .../Programming-In-Apache-Qpid-Book.xml | 6510 ------------------- .../src/programming/Programming-In-Apache-Qpid.xml | 6530 ++++++++++++++++++++ 104 files changed, 12281 insertions(+), 14357 deletions(-) delete mode 100644 doc/book/src/cpp-broker/Active-Active-Cluster.xml delete mode 100644 doc/book/src/java-broker/Add-New-Users.xml delete mode 100644 doc/book/src/java-broker/Broker-Configuration-Guide.xml delete mode 100644 doc/book/src/java-broker/Configure-ACLs.xml delete mode 100644 doc/book/src/java-broker/Configure-Java-Qpid-to-use-a-SSL-connection.xml delete mode 100644 doc/book/src/java-broker/Configure-Log4j-CompositeRolling-Appender.xml delete mode 100644 doc/book/src/java-broker/Configure-the-Broker-via-config.xml.xml delete mode 100644 doc/book/src/java-broker/Configure-the-Virtual-Hosts-via-virtualhosts.xml.xml delete mode 100644 doc/book/src/java-broker/Configuring-Management-Users.xml delete mode 100644 doc/book/src/java-broker/Configuring-Qpid-JMX-Management-Console.xml delete mode 100644 doc/book/src/java-broker/Debug-using-log4j.xml delete mode 100644 doc/book/src/java-broker/HA-Guide.xml delete mode 100644 doc/book/src/java-broker/How-to-Tune-M3-Java-Broker-Performance.xml delete mode 100644 doc/book/src/java-broker/How-to-Use-SlowConsumerDisconnect.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Authentication-Providers.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Exchanges.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Other-Services.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Ports.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Protocols.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Queues.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts-Virtual-Hosts.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Concepts.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Config-Files.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-JMX.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Other-Tooling.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-REST-API.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Web-Console.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Configuring-And-Managing.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Exchanges-Binding-Arguments.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Exchanges.xml delete mode 100644 doc/book/src/java-broker/Java-Broker-Feature-Guide.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Getting-Started.xml create mode 100644 doc/book/src/java-broker/Java-Broker-High-Availability.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Installation.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Introduction.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Miscellaneous.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Queues-Messaging-Groups.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Queues-OtherTypes.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Queues.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Alerts.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Handling-Undeliverable-Messages.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Log-Files.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime-Producer-Transaction-Timeout.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Runtime.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security-ACLs.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security-Authentication-Providers.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security-Group-Providers.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security-SSL.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security-Users-And-Groups.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Security.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores-BDB-Store.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores-Derby-Store.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores-HA-BDB-Store.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores-Memory-Store.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores-SQL-Store.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Stores.xml create mode 100644 doc/book/src/java-broker/Java-Broker-Virtual-Hosts.xml delete mode 100644 doc/book/src/java-broker/Java-Environment-Variables.xml delete mode 100644 doc/book/src/java-broker/Management-Console-Security.xml delete mode 100644 doc/book/src/java-broker/OtherQueueTypes.xml delete mode 100644 doc/book/src/java-broker/Producer-Flow-Control.xml delete mode 100644 doc/book/src/java-broker/Qpid-JMX-Management-Console-FAQ.xml delete mode 100644 doc/book/src/java-broker/Qpid-JMX-Management-Console-User-Guide.xml delete mode 100644 doc/book/src/java-broker/Qpid-JMX-Management-Console.xml delete mode 100644 doc/book/src/java-broker/Qpid-Java-Broker-Management-CLI.xml delete mode 100644 doc/book/src/java-broker/Qpid-Java-Build-How-To.xml delete mode 100644 doc/book/src/java-broker/Qpid-Java-FAQ.xml delete mode 100644 doc/book/src/java-broker/Qpid-Management-Features.xml delete mode 100644 doc/book/src/java-broker/Qpid-Troubleshooting-Guide.xml delete mode 100644 doc/book/src/java-broker/Topic-Configuration.xml create mode 100644 doc/book/src/java-broker/commonEntities.xml delete mode 100644 doc/book/src/java-broker/images/3113098.png delete mode 100644 doc/book/src/java-broker/images/3113099.png delete mode 100644 doc/book/src/java-broker/images/3113100.png delete mode 100644 doc/book/src/java-broker/images/3113101.png delete mode 100644 doc/book/src/java-broker/images/3113102.png delete mode 100644 doc/book/src/java-broker/images/3113103.png delete mode 100644 doc/book/src/java-broker/images/3113104.png delete mode 100644 doc/book/src/java-broker/images/3113105.png delete mode 100644 doc/book/src/java-broker/images/3113106.png delete mode 100644 doc/book/src/java-broker/images/3113107.png delete mode 100644 doc/book/src/java-broker/images/3113108.png delete mode 100644 doc/book/src/java-broker/images/3113109.png delete mode 100644 doc/book/src/java-broker/images/3113110.png delete mode 100644 doc/book/src/java-broker/images/3113111.png delete mode 100644 doc/book/src/java-broker/images/3113112.png delete mode 100644 doc/book/src/java-broker/images/3113113.png delete mode 100644 doc/book/src/java-broker/images/3113114.png delete mode 100644 doc/book/src/java-broker/images/3113115.png delete mode 100644 doc/book/src/java-broker/images/3113116.png delete mode 100644 doc/book/src/java-broker/images/3113117.png delete mode 100644 doc/book/src/java-broker/images/3113118.png delete mode 100644 doc/book/src/java-broker/images/3113119.png create mode 100644 doc/book/src/java-broker/images/Management-Web-Console.png delete mode 100644 doc/book/src/programming/Programming-In-Apache-Qpid-Book.xml create mode 100644 doc/book/src/programming/Programming-In-Apache-Qpid.xml (limited to 'doc/book/src') diff --git a/doc/book/src/Makefile.inc b/doc/book/src/Makefile.inc index 12cab54f8a..99d999ed7a 100644 --- a/doc/book/src/Makefile.inc +++ b/doc/book/src/Makefile.inc @@ -17,7 +17,7 @@ # under the License. # -BOOK=$(wildcard *Book.xml) +BOOK=$(wildcard *Book.xml Programming-In-Apache-Qpid.xml) XML=$(wildcard *.xml) $(wildcard ../common/*.xml) IMAGES=$(wildcard images/*.png) CSS=$(wilcard ../common/css/*.css) diff --git a/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml b/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml index 228c6a5e15..6122b12e18 100644 --- a/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml +++ b/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml @@ -53,7 +53,6 @@ - diff --git a/doc/book/src/cpp-broker/Active-Active-Cluster.xml b/doc/book/src/cpp-broker/Active-Active-Cluster.xml deleted file mode 100644 index 28db3876e2..0000000000 --- a/doc/book/src/cpp-broker/Active-Active-Cluster.xml +++ /dev/null @@ -1,561 +0,0 @@ - - - -
- Active-active Messaging Clusters - - Active-active Messaging Clusters provide fault tolerance by ensuring that every broker in a cluster has the same queues, exchanges, messages, and bindings, and allowing a client to fail over to a new broker and continue without any loss of messages if the current broker fails or becomes unavailable. Active-active refers to the fact that all brokers in the cluster can actively serve clients. Because all brokers are automatically kept in a consistent state, clients can connect to and use any broker in a cluster. Any number of messaging brokers can be run as one cluster, and brokers can be added to or removed from a cluster while it is in use. - - - High Availability Messaging Clusters are implemented using using the OpenAIS Cluster Framework. - - - An OpenAIS daemon runs on every machine in the cluster, and these daemons communicate using multicast on a particular address. Every qpidd process in a cluster joins a named group that is automatically synchronized using OpenAIS Closed Process Groups (CPG) — the qpidd processes multicast events to the named group, and CPG ensures that each qpidd process receives all the events in the same sequence. All members get an identical sequence of events, so they can all update their state consistently. - - - Two messaging brokers are in the same cluster if - - - - They run on hosts in the same OpenAIS cluster; that is, OpenAIS is configured with the same mcastaddr, mcastport and bindnetaddr, and - - - - - - They use the same cluster name. - - - - - - - - - High Availability Clustering has a cost: in order to allow each broker in a cluster to continue the work of any other broker, a cluster must replicate state for all brokers in the cluster. Because of this, the brokers in a cluster should normally be on a LAN; there should be fast and reliable connections between brokers. Even on a LAN, using multiple brokers in a cluster is somewhat slower than using a single broker without clustering. This may be counter-intuitive for people who are used to clustering in the context of High Performance Computing or High Throughput Computing, where clustering increases performance or throughput. - - - - High Availability Messaging Clusters should be used together with Red Hat Clustering Services (RHCS); without RHCS, clusters are vulnerable to the "split-brain" condition, in which a network failure splits the cluster into two sub-clusters that cannot communicate with each other. See the documentation on the --cluster-cman option for details on running using RHCS with High Availability Messaging Clusters. See the CMAN Wiki for more detail on CMAN and split-brain conditions. Use the --cluster-cman option to enable RHCS when starting the broker. - -
- Starting a Broker in a Cluster - - Clustering is implemented using the cluster.so module, which is loaded by default when you start a broker. To run brokers in a cluster, make sure they all use the same OpenAIS mcastaddr, mcastport, and bindnetaddr. All brokers in a cluster must also have the same cluster name — specify the cluster name in qpidd.conf: - - - cluster-name="local_test_cluster" - - - On RHEL6, you must create the file /etc/corosync/uidgid.d/qpidd to tell Corosync the name of the user running the broker.By default, the user is qpidd: - - - - uidgid { - uid: qpidd - gid: qpidd - } - - - On RHEL5, the primary group for the process running qpidd must be the ais group. If you are running qpidd as a service, it is run as the qpidd user, which is already in the ais group. If you are running the broker from the command line, you must ensure that the primary group for the user running qpidd is ais. You can set the primary group using newgrp: - - - $ newgrp ais - - - You can then run the broker from the command line, specifying the cluster name as an option. - - - [jonathan@localhost]$ qpidd --cluster-name="local_test_cluster" - - - All brokers in a cluster must have identical configuration, with a few exceptions noted below. They must load the same set of plug-ins, and have matching configuration files and command line arguments. The should also have identical ACL files and SASL databases if these are used. If one broker uses persistence, all must use persistence — a mix of transient and persistent brokers is not allowed. Differences in configuration can cause brokers to exit the cluster. For instance, if different ACL settings allow a client to access a queue on broker A but not on broker B, then publishing to the queue will succeed on A and fail on B, so B will exit the cluster to prevent inconsistency. - - - The following settings can differ for brokers on a given cluster: - - - - - logging options - - - - - - cluster-url — if set, it will be different for each broker. - - - - - - port — brokers can listen on different ports. - - - - - - - The qpid log contains entries that record significant clustering events, e.g. when a broker becomes a member of a cluster, the membership of a cluster is changed, or an old journal is moved out of the way. For instance, the following message states that a broker has been added to a cluster as the first node: - - - - 2009-07-09 18:13:41 info 127.0.0.1:1410(READY) member update: 127.0.0.1:1410(member) - 2009-07-09 18:13:41 notice 127.0.0.1:1410(READY) first in cluster - - - - If you are using SELinux, the qpidd process and OpenAIS must have the same SELinux context, or else SELinux must be set to permissive mode. If both qpidd and OpenAIS are run as services, they have the same SELinux context. If both OpenAIS and qpidd are run as user processes, they have the same SELinux context. If one is run as a service, and the other is run as a user process, they have different SELinux contexts. - - - - - The following options are available for clustering: - - - Options for High Availability Messaging Cluster - - - - - - - Options for High Availability Messaging Cluster - - - - - - - - - --cluster-name NAME - - - Name of the Messaging Cluster to join. A Messaging Cluster consists of all brokers started with the same cluster-name and openais configuration. - - - - - - --cluster-size N - - - Wait for at least N initial members before completing cluster initialization and serving clients. Use this option in a persistent cluster so all brokers in a persistent cluster can exchange the status of their persistent store and do consistency checks before serving clients. - - - - - - --cluster-url URL - - - An AMQP URL containing the local address that the broker advertizes to clients for fail-over connections. This is different for each host. By default, all local addresses for the broker are advertized. You only need to set this if - - - - Your host has more than one active network interface, and - - - - - - You want to restrict client fail-over to a specific interface or interfaces. - - - - - - Each broker in the cluster is specified using the following form: - - url = ["amqp:"][ user ["/" password] "@" ] protocol_addr - ("," protocol_addr)* - protocol_addr = tcp_addr / rmda_addr / ssl_addr / ... - tcp_addr = ["tcp:"] host [":" port] - rdma_addr = "rdma:" host [":" port] - ssl_addr = "ssl:" host [":" port] - - In most cases, only one address is advertized, but more than one address can be specified in if the machine running the broker has more than one network interface card, and you want to allow clients to connect using multiple network interfaces. Use a comma delimiter (",") to separate brokers in the URL. Examples: - - - - amqp:tcp:192.168.1.103:5672 advertizes a single address to the broker for failover. - - - - - - amqp:tcp:192.168.1.103:5672,tcp:192.168.1.105:5672 advertizes two different addresses to the broker for failover, on two different network interfaces. - - - - - - - - - - - - --cluster-cman - - - - CMAN protects against the "split-brain" condition, in which a network failure splits the cluster into two sub-clusters that cannot communicate with each other. When "split-brain" occurs, each of the sub-clusters can access shared resources without knowledge of the other sub-cluster, resulting in corrupted cluster integrity. - - - To avoid "split-brain", CMAN uses the notion of a "quorum". If more than half the cluster nodes are active, the cluster has quorum and can act. If half (or fewer) nodes are active, the cluster does not have quorum, and all cluster activity is stopped. There are other ways to define the quorum for particular use cases (e.g. a cluster of only 2 members), see the CMAN Wiki - for more detail. - - - When enabled, the broker will wait until it belongs to a quorate cluster before accepting client connections. It continually monitors the quorum status and shuts down immediately if the node it runs on loses touch with the quorum. - - - - - - - - --cluster-username - - - SASL username for connections between brokers. - - - - - - --cluster-password - - - SASL password for connections between brokers. - - - - - - --cluster-mechanism - - - SASL authentication mechanism for connections between brokers - - - - - - - - -
- - If a broker is unable to establish a connection to another broker in the cluster, the log will contain SASL errors, e.g: - - - 2009-aug-04 10:17:37 info SASL: Authentication failed: SASL(-13): user not found: Password verification failed - - - You can set the SASL user name and password used to connect to other brokers using the cluster-username and cluster-password properties when you start the broker. In most environment, it is easiest to create an account with the same user name and password on each broker in the cluster, and use these as the cluster-username and cluster-password. You can also set the SASL mode using cluster-mechanism. Remember that any mechanism you enable for broker-to-broker communication can also be used by a client, so do not enable cluster-mechanism=ANONYMOUS in a secure environment. - - - Once the cluster is running, run qpid-cluster to make sure that the brokers are running as one cluster. See the following section for details. - - - If the cluster is correctly configured, queues and messages are replicated to all brokers in the cluster, so an easy way to test the cluster is to run a program that routes messages to a queue on one broker, then to a different broker in the same cluster and read the messages to make sure they have been replicated. The drain and spout programs can be used for this test. - - -
- -
- qpid-cluster - - qpid-cluster is a command-line utility that allows you to view information on a cluster and its brokers, disconnect a client connection, shut down a broker in a cluster, or shut down the entire cluster. You can see the options using the --help option: - - - $ ./qpid-cluster --help - - - Usage: qpid-cluster [OPTIONS] [broker-addr] - - broker-addr is in the form: [username/password@] hostname | ip-address [:<port>] - ex: localhost, 10.1.1.7:10000, broker-host:10000, guest/guest@localhost - - Options: - -C [--all-connections] View client connections to all cluster members - -c [--connections] ID View client connections to specified member - -d [--del-connection] HOST:PORT - Disconnect a client connection - -s [--stop] ID Stop one member of the cluster by its ID - -k [--all-stop] Shut down the whole cluster - -f [--force] Suppress the 'are-you-sure?' prompt - -n [--numeric] Don't resolve names - - - Let's connect to a cluster and display basic information about the cluser and its brokers. When you connect to the cluster using qpid-tool, you can use the host and port for any broker in the cluster. For instance, if a broker in the cluster is running on localhost on port 6664, you can start qpid-tool like this: - - - - $ qpid-cluster localhost:6664 - - - Here is the output: - - - - Cluster Name: local_test_cluster - Cluster Status: ACTIVE - Cluster Size: 3 - Members: ID=127.0.0.1:13143 URL=amqp:tcp:192.168.1.101:6664,tcp:192.168.122.1:6664,tcp:10.16.10.62:6664 - : ID=127.0.0.1:13167 URL=amqp:tcp:192.168.1.101:6665,tcp:192.168.122.1:6665,tcp:10.16.10.62:6665 - : ID=127.0.0.1:13192 URL=amqp:tcp:192.168.1.101:6666,tcp:192.168.122.1:6666,tcp:10.16.10.62:6666 - - - The ID for each broker in cluster is given on the left. For instance, the ID for the first broker in the cluster is 127.0.0.1:13143. The URL in the output is the broker's advertized address. Let's use the ID to shut the broker down using the --stop command: - - - $ ./qpid-cluster localhost:6664 --stop 127.0.0.1:13143 - - -
- -
- Failover in Clients - - If a client is connected to a broker, the connection fails if the broker crashes or is killed. If heartbeat is enabled for the connection, a connection also fails if the broker hangs, the machine the broker is running on fails, or the network connection to the broker is lost — the connection fails no later than twice the heartbeat interval. - - - When a client's connection to a broker fails, any sent messages that have been acknowledged to the sender will have been replicated to all brokers in the cluster, any received messages that have not yet been acknowledged by the receiving client requeued to all brokers, and the client API notifies the application of the failure by throwing an exception. - - - Clients can be configured to automatically reconnect to another broker when it receives such an exception. Any messages that have been sent by the client, but not yet acknowledged as delivered, are resent. Any messages that have been read by the client, but not acknowledged, are delivered to the client. - - - TCP is slow to detect connection failures. A client can configure a connection to use a heartbeat to detect connection failure, and can specify a time interval for the heartbeat. If heartbeats are in use, failures will be detected no later than twice the heartbeat interval. The Java JMS client enables hearbeat by default. See the sections on Failover in Java JMS Clients and Failover in C++ Clients for the code to enable heartbeat. - -
- Failover in Java JMS Clients - - In Java JMS clients, client failover is handled automatically if it is enabled in the connection. Any messages that have been sent by the client, but not yet acknowledged as delivered, are resent. Any messages that have been read by the client, but not acknowledged, are sent to the client. - - - You can configure a connection to use failover using the failover property: - - - - connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'&failover='failover_exchange' - - - This property can take three values: - - - Failover Modes - - failover_exchange - - - If the connection fails, fail over to any other broker in the cluster. - - - - - - - roundrobin - - - If the connection fails, fail over to one of the brokers specified in the brokerlist. - - - - - - - singlebroker - - - Failover is not supported; the connection is to a single broker only. - - - - - - - - - In a Connection URL, heartbeat is set using the idle_timeout property, which is an integer corresponding to the heartbeat period in seconds. For instance, the following line from a JNDI properties file sets the heartbeat time out to 3 seconds: - - - - connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672',idle_timeout=3 - - -
- -
- Failover and the Qpid Messaging API - - The Qpid Messaging API also supports automatic reconnection in the event a connection fails. . Senders can also be configured to replay any in-doubt messages (i.e. messages whice were sent but not acknowleged by the broker. See "Connection Options" and "Sender Capacity and Replay" in Programming in Apache Qpid for details. - - - In C++ and python clients, heartbeats are disabled by default. You can enable them by specifying a heartbeat interval (in seconds) for the connection via the 'heartbeat' option. - - - See "Cluster Failover" in Programming in Apache Qpid for details on how to keep the client aware of cluster membership. - - -
- - -
- -
- Error handling in Clusters - - If a broker crashes or is killed, or a broker machine failure, broker connection failure, or a broker hang is detected, the other brokers in the cluster are notified that it is no longer a member of the cluster. If a new broker is joined to the cluster, it synchronizes with an active broker to obtain the current cluster state; if this synchronization fails, the new broker exit the cluster and aborts. - - - If a broker becomes extremely busy and stops responding, it stops accepting incoming work. All other brokers continue processing, and the non-responsive node caches all AIS traffic. When it resumes, the broker completes processes all cached AIS events, then accepts further incoming work. - - - Broker hangs are only detected if the watchdog plugin is loaded and the --watchdog-interval option is set. The watchdog plug-in kills the qpidd broker process if it becomes stuck for longer than the watchdog interval. In some cases, e.g. certain phases of error resolution, it is possible for a stuck process to hang other cluster members that are waiting for it to send a message. Using the watchdog, the stuck process is terminated and removed from the cluster, allowing other members to continue and clients of the stuck process to fail over to other members. - - - Redundancy can also be achieved directly in the AIS network by specifying more than one network interface in the AIS configuration file. This causes Totem to use a redundant ring protocol, which makes failure of a single network transparent. - - - Redundancy can be achieved at the operating system level by using NIC bonding, which combines multiple network ports into a single group, effectively aggregating the bandwidth of multiple interfaces into a single connection. This provides both network load balancing and fault tolerance. - - - If any broker encounters an error, the brokers compare notes to see if they all received the same error. If not, the broker removes itself from the cluster and shuts itself down to ensure that all brokers in the cluster have consistent state. For instance, a broker may run out of disk space; if this happens, the broker shuts itself down. Examining the broker's log can help determine the error and suggest ways to prevent it from occuring in the future. - - -
- -
- Persistence in High Availability Message Clusters - - Persistence and clustering are two different ways to provide reliability. Most systems that use a cluster do not enable persistence, but you can do so if you want to ensure that messages are not lost even if the last broker in a cluster fails. A cluster must have all transient or all persistent members, mixed clusters are not allowed. Each broker in a persistent cluster has it's own independent replica of the cluster's state it its store. - -
- Clean and Dirty Stores - - When a broker is an active member of a cluster, its store is marked "dirty" because it may be out of date compared to other brokers in the cluster. If a broker leaves a running cluster because it is stopped, it crashes or the host crashes, its store continues to be marked "dirty". - - - If the cluster is reduced to a single broker, its store is marked "clean" since it is the only broker making updates. If the cluster is shut down with the command qpid-cluster -k then all the stores are marked clean. - - - When a cluster is initially formed, brokers with clean stores read from their stores. Brokers with dirty stores, or brokers that join after the cluster is running, discard their old stores and initialize a new store with an update from one of the running brokers. The --truncate option can be used to force a broker to discard all existing stores even if they are clean. (A dirty store is discarded regardless.) - - - Discarded stores are copied to a back up directory. The active store is in <data-dir>/rhm. Back-up stores are in <data-dir>/_cluster.bak.<nnnn>/rhm, where <nnnn> is a 4 digit number. A higher number means a more recent backup. - - -
- -
- Starting a persistent cluster - - When starting a persistent cluster broker, set the cluster-size option to the number of brokers in the cluster. This allows the brokers to wait until the entire cluster is running so that they can synchronize their stored state. - - - The cluster can start if: - - - - - - all members have empty stores, or - - - - - - at least one member has a clean store - - - - - - - - - All members of the new cluster will be initialized with the state from a clean store. - - -
- -
- Stopping a persistent cluster - - To cleanly shut down a persistent cluster use the command qpid-cluster -k. This causes all brokers to synchronize their state and mark their stores as "clean" so they can be used when the cluster restarts. - - -
- -
- Starting a persistent cluster with no clean store - - If the cluster has previously had a total failure and there are no clean stores then the brokers will fail to start with the log message Cannot recover, no clean store. If this happens you can start the cluster by marking one of the stores "clean" as follows: - - - - - Move the latest store backup into place in the brokers data-directory. The backups end in a 4 digit number, the latest backup is the highest number. - - - - cd <data-dir> - mv rhm rhm.bak - cp -a _cluster.bak.<nnnn>/rhm . - - - - - - Mark the store as clean: - qpid-cluster-store -c <data-dir> - - - - - - - - - Now you can start the cluster, all members will be initialized from the store you marked as clean. - - -
- -
- Isolated failures in a persistent cluster - - A broker in a persistent cluster may encounter errors that other brokers in the cluster do not; if this happens, the broker shuts itself down to avoid making the cluster state inconsistent. For example a disk failure on one node will result in that node shutting down. Running out of storage capacity can also cause a node to shut down because because the brokers may not run out of storage at exactly the same point, even if they have similar storage configuration. To avoid unnecessary broker shutdowns, make sure the queue policy size of each durable queue is less than the capacity of the journal for the queue. - - -
- - -
- - -
diff --git a/doc/book/src/cpp-broker/Active-Passive-Cluster.xml b/doc/book/src/cpp-broker/Active-Passive-Cluster.xml index 805ceb06e0..8a6403c2b5 100644 --- a/doc/book/src/cpp-broker/Active-Passive-Cluster.xml +++ b/doc/book/src/cpp-broker/Active-Passive-Cluster.xml @@ -55,30 +55,45 @@ under the License. Avoiding message loss In order to avoid message loss, the primary broker delays - acknowledgment of messages received from clients until the - message has been replicated to and acknowledged by all of the back-up + acknowledgment of messages received from clients until the message has + been replicated to and acknowledged by all of the back-up brokers. This means that + all acknowledged messages are safely stored on all the backup brokers. - Clients buffer unacknowledged messages and re-send them in the event of - a fail-over. + Clients keep unacknowledged messages in a buffer + + + You can control the maximum number of messages in the buffer by setting the + client's capacity. For details of how to set the capacity + in client code see "Using the Qpid Messaging API" in + Programming in Apache Qpid. + + + until they are acknowledged by the primary. If the primary fails, clients will + fail-over to the new primary and re-send all their + unacknowledged messages. Clients must use "at-least-once" reliability to enable re-send of unacknowledged messages. This is the default behavior, no options need be set to enable it. For details of client addressing options see "Using the Qpid Messaging API" - in Programming in Apache Qpid + in Programming in Apache Qpid. - If the primary crashes before a message is replicated to - all the backups, the client will re-send the message when it fails over - to the new primary. + + + So if the primary crashes, all the acknowledged + messages will be available on the backup that takes over as the new + primary. The unacknowledged messages will be + re-sent by the clients. Thus no messages are lost. Note that this means it is possible for messages to be - duplicated. In the event of a failure it is - possible for a message to be both received by the backup that becomes - the new primary and re-sent by the client. + duplicated. In the event of a failure it is possible for a + message to received by the backup that becomes the new primary + and re-sent by the client. The application must take steps + to identify and eliminate duplicates. When a new primary is promoted after a fail-over it is initially in @@ -87,6 +102,11 @@ under the License. primary. This protects those messages against a failure of the new primary until the backups have a chance to connect and catch up. + + Not all messages need to be replicated to the back-up brokers. If a + message is consumed and acknowledged by a regular client before it has + been replicated to a backup, then it doesn't need to be replicated. + Status of a HA broker @@ -134,67 +154,35 @@ under the License.
- Replacing the old cluster module + Limitations - The High Availability (HA) module replaces the previous - active-active cluster module. The new active-passive - approach has several advantages compared to the existing active-active cluster - module. - - - It does not depend directly on openais or corosync. It does not use multicast - which simplifies deployment. - - - It is more portable: in environments that don't support corosync, it can be - integrated with a resource manager available in that environment. - - - Replication to a disaster recovery site can be handled as - simply another node in the cluster, it does not require a separate replication - mechanism. - - - It can take advantage of features provided by the resource manager, for example - virtual IP addresses. - - - Improved performance and scalability due to better use of multiple CPUs - - + There are a some known limitations in the current implementation. These + will be fixed in furture versions. -
-
- Limitations - Transactional changes to queue state are not replicated atomically. If the - primary crashes during a transaction, it is possible that the backup could - contain only part of the changes introduced by a transaction. - - - Not yet integrated with the persistent store. A persistent broker must have its - store erased before joining an existing cluster. If the entire cluster fails, - there are no tools to help identify the most recent store. In the future a - persistent broker will be able to use its stored messages to avoid downloading - messages from the primary when joining a cluster. - - - Configuration changes (creating or deleting queues, exchanges and bindings) are - replicated asynchronously. Management tools used to make changes will consider - the change complete when it is complete on the primary, it may not yet be - replicated to all the backups. + + Transactional changes to queue state are not replicated atomically. If + the primary crashes during a transaction, it is possible that the + backup could contain only part of the changes introduced by a + transaction. + - Deletions made immediately after a failure (before all the backups are ready) - may be lost on a backup. Queues, exchange or bindings that were deleted on the - primary could re-appear if that backup is promoted to primary on a subsequent - failure. + + Configuration changes (creating or deleting queues, exchanges and + bindings) are replicated asynchronously. Management tools used to + make changes will consider the change complete when it is complete + on the primary, it may not yet be replicated to all the backups. + - Federated links from the primary will be lost in fail over, - they will not be re-connected to the new primary. Federation links - to the primary can fail over. + + Federated links from the primary will be lost + in fail over, they will not be re-connected to the new + primary. Federation links to the primary will + fail over. +
@@ -245,6 +233,14 @@ under the License. Set to "yes" to have the broker join a cluster. + + + ha-queue-replication yes|no + + + Enable replication of specific queues without joining a cluster, see . + + ha-brokers-url URL @@ -252,7 +248,7 @@ under the License. The URL - + The full format of the URL is given by this grammar: @@ -264,10 +260,9 @@ ssl_addr = "ssl:" host [":" port]' - used by cluster brokers to connect to each other. The URL can - contain a list of all the broker addresses or it can contain a single - virtual IP address. If a list is used it is comma separated, for example - amqp:node1.exaple.com,node2.exaple.com,node3.exaple.com + used by cluster brokers to connect to each other. The URL should + contain a comma separated list of the broker addresses, rather than a + virtual IP address. @@ -275,20 +270,23 @@ ssl_addr = "ssl:" host [":" port]' ha-public-url URL - The URL that is advertised to clients. This defaults to the - ha-brokers-url URL above, and has the same format. A - virtual IP address is recommended for the public URL as it simplifies - deployment and hides changes to the cluster membership from clients. + The URL is advertised to + clients as the "known-hosts" for fail-over. It can be a list or + a single virtual IP address. A virtual IP address is recommended. - This option allows you to put client traffic on a different network from - broker traffic, which is recommended. + Using this option you can put client and broker traffic on + separate networks, which is recommended. + + + Note: When HA clustering is enabled the broker option + known-hosts-url is ignored and over-ridden by + the ha-public-url setting. ha-replicate VALUE - Specifies whether queues and exchanges are replicated by default. @@ -330,6 +328,15 @@ ssl_addr = "ssl:" host [":" port]' + + link-heartbeat-interval SECONDS + + + Heartbeat interval for replication links. The link will be assumed broken + if there is no heartbeat for twice the interval. + + + @@ -382,7 +389,7 @@ ssl_addr = "ssl:" host [":" port]' clustered services using cman and rgmanager. It will show you how to configure an active-passive, hot-standby qpidd HA cluster with rgmanager. - + You must provide a cluster.conf file to configure cman and rgmanager. Here is @@ -532,22 +539,28 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl
- Creating replicated queues and exchanges + Controlling replication of queues and exchanges By default, queues and exchanges are not replicated automatically. You can change the default behavior by setting the ha-replicate configuration option. It has one of the following values: - all: Replicate everything automatically: queues, - exchanges, bindings and messages. + + all: Replicate everything automatically: queues, + exchanges, bindings and messages. + - configuration: Replicate the existence of queues, - exchange and bindings but don't replicate messages. + + configuration: Replicate the existence of queues, + exchange and bindings but don't replicate messages. + - none: Don't replicate anything, this is the default. + + none: Don't replicate anything, this is the default. + @@ -575,6 +588,18 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl "myqueue;{create:always,node:{x-declare:{arguments:{'qpid.replicate':all}}}}" + + There are some built-in exchanges created automatically by the broker, these + exchangs are never replicated. The built-in exchanges are the default (nameless) + exchange, the AMQP standard exchanges (amq.direct, amq.topic, amq.fanout and + amq.match) and the management exchanges (qpid.management, qmf.default.direct and + qmf.default.topic) + + + Note that if you bind a replicated queue to one of these exchanges, the + binding wil not be replicated, so the queue will not + have the binding after a fail-over. +
@@ -588,12 +613,17 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl each type of client). There are two possibilities - The URL contains multiple addresses, one for each broker in the cluster. + + The URL contains multiple addresses, one for each broker in the cluster. + - The URL contains a single virtual IP address - that is assigned to the primary broker by the resource manager. - Only if the resource manager supports virtual IP addresses + + The URL contains a single virtual IP address + that is assigned to the primary broker by the resource manager. + Only if the resource manager supports virtual IP + addresses + In the first case, clients will repeatedly re-try each address in the URL @@ -790,10 +820,10 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl To integrate with a different resource manager you must configure it to: - Start a qpidd process on each node of the cluster. - Restart qpidd if it crashes. - Promote exactly one of the brokers to primary. - Detect a failure and promote a new primary. + Start a qpidd process on each node of the cluster. + Restart qpidd if it crashes. + Promote exactly one of the brokers to primary. + Detect a failure and promote a new primary. @@ -821,6 +851,30 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl or to simulate a cluster on a single node. For deployment, a resource manager is required.
+
+ Replicating specific queues + + In addition to the automatic replication performed in a cluster, you can + set up replication for specific queues between arbitrary brokers, even if + the brokers are not members of a cluster. The command: + + + qpid-ha replicate QUEUE REMOTE-BROKER + + + sets up replication of QUEUE on REMOTE-BROKER to QUEUE on the current broker. + + + Set the configuration option + ha-queue-replication=yes on both brokers to enable this + feature on non-cluster brokers. It is automatically enabled for brokers + that are part of a cluster. + + + Note that this feature does not provide automatic fail-over, for that you + need to run a cluster. + +
Authorization - In Qpid, Authorization specifies which actions can be performed by each authenticated user using an Access Control List (ACL). Use the --acl-file command to load the access control list. The filename should have a .acl extension: + In Qpid, Authorization specifies which actions can be performed by each authenticated user using an Access Control List (ACL). + + + Use the --acl-file command to load the access control list. The filename should have a .acl extension: -$ qpidd --acl-file ./aclfilename.acl + $ qpidd --acl-file ./aclfilename.acl Each line in an ACL file grants or denies specific rights to a user. If the last line in an ACL file is acl deny all all, the ACL uses deny mode, and only those rights that are explicitly allowed are granted: -acl allow rajith@QPID all all -acl deny all all + acl allow rajith@QPID all all + acl deny all all On this server, rajith@QPID can perform any action, but nobody else can. Deny mode is the default, so the previous example is equivalent to the following ACL file: -acl allow rajith@QPID all all + acl allow rajith@QPID all all + + + Alternatively the ACL file may use allow mode by placing: + + + acl allow all all + + as the final line in the ACL file. In allow mode all actions by all users are allowed unless otherwise denied by specific ACL rules. + The ACL rule which selects deny mode or allow mode must be the last line in the ACL rule file. + ACL syntax allows fine-grained access rights for specific actions: -acl allow carlt@QPID create exchange name=carl.* -acl allow fred@QPID create all -acl allow all consume queue -acl allow all bind exchange -acl deny all all + acl allow carlt@QPID create exchange name=carl.* + acl allow fred@QPID create all + acl allow all consume queue + acl allow all bind exchange + acl deny all all An ACL file can define user groups, and assign permissions to them: -group admin ted@QPID martin@QPID -acl allow admin create all -acl deny all all + group admin ted@QPID martin@QPID + acl allow admin create all + acl deny all all + + + Performance Note: Most ACL queries are performed infrequently. The overhead associated with + ACL passing an allow or deny decision on the creation of a queue is negligible + compared to actually creating and using the queue. One notable exception is the publish exchange + query. ACL files with no publish exchange rules are noted and the broker short circuits the logic + associated with the per-messsage publish exchange ACL query. + However, if an ACL file has any publish exchange rules + then the broker is required to perform a publish exchange query for each message published. + Users with performance critical applications are encouraged to structure exchanges, queues, and bindings so that + the publish exchange ACL rules are unnecessary. + +
ACL Syntax ACL rules must be on a single line and follow this syntax: = [user-list] [group-name-list] - -permission = [allow|allow-log|deny|deny-log] -action = [consume|publish|create|access|bind|unbind|delete|purge|update] -object = [virtualhost|queue|exchange|broker|link|route|method] -property = [name|durable|owner|routingkey|autodelete|exclusive| - type|alternate|queuename|schemapackage|schemaclass| - queuemaxsizelowerlimit|queuemaxsizeupperlimit| - queuemaxcountlowerlimit|queuemaxcountupperlimit] - -acl permission {||"all"} {action|"all"} [object|"all" - [property= ...]] + user = username[/domain[@realm]] + user-list = user1 user2 user3 ... + group-name-list = group1 group2 group3 ... + + group = [user-list] [group-name-list] + + permission = [allow | allow-log | deny | deny-log] + action = [consume | publish | create | access | + bind | unbind | delete | purge | update] + object = [queue | exchange | broker | link | method] + property = [name | durable | owner | routingkey | + autodelete | exclusive |type | + alternate | queuename | + schemapackage | schemaclass | + queuemaxsizelowerlimit | + queuemaxsizeupperlimit | + queuemaxcountlowerlimit | + queuemaxcountupperlimit | + filemaxsizelowerlimit | + filemaxsizeupperlimit | + filemaxcountlowerlimit | + filemaxcountupperlimit ] + + acl permission {||"all"} {action|"all"} [object|"all" + [property= ...]] ]]> ACL rules can also include a single object name (or the keyword all) and one or more property name value pairs in the form property=value @@ -463,7 +498,9 @@ acl permission {||"all"} {action|"all"} [object|"all" - Applied on a per message basis on publish message transfers, this rule consumes the most resources + Applied on a per message basis + to verify that the user has rights to publish to the given + exchange with the given routingkey. @@ -647,49 +684,49 @@ acl permission {||"all"} {action|"all"} [object|"all" name String Object name, such as a queue name or exchange name. - . + durable Boolean Indicates the object is durable - CREATE QUEUE, CREATE EXCHANGE + CREATE QUEUE, CREATE EXCHANGE, ACCESS QUEUE, ACCESS EXCHANGE routingkey String Specifies routing key - BIND EXCHANGE, UNBIND EXCHANGE, ACCESS EXCHANGE + BIND EXCHANGE, UNBIND EXCHANGE, ACCESS EXCHANGE, PUBLISH EXCHANGE autodelete Boolean Indicates whether or not the object gets deleted when the connection is closed - CREATE QUEUE + CREATE QUEUE, ACCESS QUEUE exclusive Boolean Indicates the presence of an exclusive flag - CREATE QUEUE + CREATE QUEUE, ACCESS QUEUE type String Type of exchange, such as topic, fanout, or xml - CREATE EXCHANGE + CREATE EXCHANGE, ACCESS EXCHANGE alternate String Name of the alternate exchange - CREATE EXCHANGE, CREATE QUEUE + CREATE EXCHANGE, CREATE QUEUE, ACCESS EXCHANGE, ACCESS QUEUE queuename String Name of the queue - ACCESS EXCHANGE + ACCESS EXCHANGE, BIND EXCHANGE, UNBIND EXCHANGE schemapackage @@ -706,119 +743,571 @@ acl permission {||"all"} {action|"all"} [object|"all" queuemaxsizelowerlimit Integer - Minimum value for queue.max_size - CREATE QUEUE + Minimum value for queue.max_size (memory bytes) + CREATE QUEUE, ACCESS QUEUE queuemaxsizeupperlimit Integer - Maximum value for queue.max_size - CREATE QUEUE + Maximum value for queue.max_size (memory bytes) + CREATE QUEUE, ACCESS QUEUE queuemaxcountlowerlimit Integer - Minimum value for queue.max_count - CREATE QUEUE + Minimum value for queue.max_count (messages) + CREATE QUEUE, ACCESS QUEUE queuemaxcountupperlimit Integer - Maximum value for queue.max_count - CREATE QUEUE + Maximum value for queue.max_count (messages) + CREATE QUEUE, ACCESS QUEUE + + + filemaxsizelowerlimit + Integer + Minimum value for file.max_size (64kb pages) + CREATE QUEUE, ACCESS QUEUE + + + filemaxsizeupperlimit + Integer + Maximum value for file.max_size (64kb pages) + CREATE QUEUE, ACCESS QUEUE + + + filemaxcountlowerlimit + Integer + Minimum value for file.max_count (files) + CREATE QUEUE, ACCESS QUEUE + + + filemaxcountupperlimit + Integer + Maximum value for file.max_count (files) + CREATE QUEUE, ACCESS QUEUE - - - - + +
+ ACL Action-Object-Property Tuples + + Not every ACL action is applicable to every ACL object. Furthermore, not every property may be + specified for every action-object pair. + The following table enumerates which action and object pairs are allowed. + The table also lists which optional ACL properties are allowed to qualify + action-object pairs. + + + The access action is called with different argument + lists for the exchange and queue objects. + A separate column shows the AMQP 0.10 method that the Access ACL rule is satisfying. + Write separate rules with the additional arguments for the declare + and bind methods and include these rules in the ACL file + before the rules for the query method. + + + + ACL Properties Allowed for each Action and Object + + + + Action + Object + Properties + Method + + + + + access + broker + + + + access + exchange + name type alternate durable + declare + + + access + exchange + name queuename routingkey + bound + + + access + exchange + name + query + + + access + method + name schemapackage schemaclass + + + + access + queue + name alternate durable exclusive autodelete policy queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit filemaxsizelowerlimit filemaxsizeupperlimit filemaxcountlowerlimit filemaxcountupperlimit + declare + + + access + queue + name + query + + + bind + exchange + name queuename routingkey + + + + consume + queue + name + + + + create + exchange + name type alternate durable + + + + create + link + name + + + + create + queue + name alternate durable exclusive autodelete policy queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit filemaxsizelowerlimit filemaxsizeupperlimit filemaxcountlowerlimit filemaxcountupperlimit + + + + delete + exchange + name + + + + delete + queue + name + + + + publish + exchange + name routingkey + + + + purge + queue + name + + + + unbind + exchange + name queuename routingkey + + + + update + broker + + + + + +
+ + + +
ACL Syntactic Conventions - - In ACL files, the following syntactic conventions apply: +
+ Comments + + + + + A line starting with the # character is considered a comment and is ignored. + + + + + Embedded comments and trailing comments are not allowed. The # is commonly found in routing keys and other AMQP literals which occur naturally in ACL rule specifications. + + + + +
+
+ White Space + + + + Empty lines and lines that contain only whitespace (' ', '\f', '\n', '\r', '\t', '\v') are ignored. + + + + + Additional whitespace between and after tokens is allowed. + + + + + Group and Acl definitions must start with group and acl respectively and with no preceding whitespace. + + + +
+
+ Character Set + + + + ACL files use 7-bit ASCII characters only + + + + + Group names may contain only - - - A line starting with the # character is considered a comment and is ignored. - - - - - - Empty lines and lines that contain only whitespace (' ', '\f', '\n', '\r', '\t', '\v') are ignored. - - - - - - All tokens are case sensitive. name1 is not the same as Name1 and create is not the same as CREATE. - - - - - - Group lists can be extended to the following line by terminating the line with the \ character. - - - - - - Additional whitespace - that is, where there is more than one whitespace character - between and after tokens is ignored. Group and ACL definitions must start with either group or acl and with no preceding whitespace. - - - - - - All ACL rules are limited to a single line of at most 1024 characters. - - - - - - Rules are interpreted from the top of the file down until a matching rule is obtained. The matching rule then controls the allow or deny decision. - - - - - - The keyword all is reserved and may be used in ACL rules to match all individuals and groups, all actions, or all objects. - - - - - - By default ACL files are in 'Deny Mode' and deny all actions by all users. That is, there is an implicit acl deny all all rule appended to the ACL rule list. - - - - - - Group names may contain only a-z, A-Z, 0-9, - hyphen and _ underscore. - - - - - - Individual user names may contain only a-z, A-Z, 0-9, - hyphen, _ underscore, . period, @ ampersand, and / slash. - - - - - - Rules must be preceded by any group definitions they can use. Any name not defined as a group will be assumed to be that of an individual. - - - - + [a-z] + [A-Z] + [0-9] + '-' hyphen + '_' underscore + + + + + + Individual user names may contain only + + [a-z] + [A-Z] + [0-9] + '-' hyphen + '_' underscore + '.' period + '@' ampersand + '/' slash + + + +
+
+ Case Sensitivity + + + + All tokens are case sensitive. name1 is not the same as Name1 and create is not the same as CREATE. + + + +
+
+ Line Continuation + + + + Group lists can be extended to the following line by terminating the line with the '\' character. No other ACL file lines may be continued. + + + + + Group specification lines may be continued only after the group name or any of the user names included in the group. See example below. + + + + + Lines consisting solely of a '\' character are not permitted. + + + + + The '\' continuation character is recognized only if it is the last character in the line. Any characters after the '\' are not permitted. + + + + - +
+
+ Line Length + + + + ACL file lines are limited to 1024 characters. + + + +
+ + +
+ ACL File Keywords + ACL reserves several words for convenience and for context sensitive substitution. + +
+ The <command>all</command> Keyword + The keyword all is reserved. It may be used in ACL rules to match all individuals and groups, all actions, or all objects. + + acl allow all create queue + acl allow bob@QPID all queue + acl allow bob@QPID create all + +
+ +
+ User Name and Domain Name Keywords + + In the C++ Broker 0.20 a simple set of user name and domain name substitution variable keyword tokens is defined. This provides administrators with an easy way to describe private or shared resources. + + + Symbol substitution is allowed in the ACL file anywhere that text is supplied for a property value. + + + In the following table an authenticated user named bob.user@QPID.COM has his substitution keywords expanded. + + + ACL User Name and Domain Name Substitution Keywords + + + + Keyword + Expansion + + + + + ${userdomain} + bob_user_QPID_COM + + + ${user} + bob_user + + + ${domain} + QPID_COM + + + +
+ + + + + + The original user name has the period “.” and ampersand “@” characters translated into underscore “_”. This allows substitution to work when the substitution keyword is used in a routingkey in the Acl file. + + + The Acl processing matches ${userdomain} before matching either ${user} or ${domain}. Rules that specify the combination ${user}_${domain} will never match. + + + + + +
+ +
+ +
+ Wildcards + ACL privides two types of wildcard matching to provide flexibility in writing rules. + +
+ Property Value Wildcard + + Text specifying a property value may end with a single trailing * character. + This is a simple wildcard match indicating that strings which match up to that point are matches for the ACL property rule. + An ACL rule such as + + + acl allow bob@QPID create queue name=bob* + + + allow user bob@QPID to create queues named bob1, bob2, bobQueue3, and so on. + +
+ +
+ Topic Routing Key Wildcard + + In the C++ Broker 0.20 the logic governing the ACL Match has changed for each ACL rule that contains a routingkey property. + The routingkey property is matched according to Topic Exchange match logic the broker uses when it distributes messages published to a topic exchange. + + + Routing keys are hierarchical where each level is separated by a period: + + weather.usa + weather.europe.germany + weather.europe.germany.berlin + company.engineering.repository + + + + Within the routing key hierarchy two wildcard characters are defined. + + * matches one field + # matches zero or more fields + + + + Suppose an ACL rule file is: + + + + acl allow-log uHash1@COMPANY publish exchange name=X routingkey=a.#.b + acl deny all all + + + + When user uHash1@COMPANY attempts to publish to exchange X the ACL will return these results: + + + Topic Exchange Wildcard Match Examples + + + + routingkey in publish to exchange X + result + + + + + a.b + allow-log + + + a.x.b + allow-log + + + a.x.y.zz.b + allow-log + + + a.b. + deny + + + q.x.b + deny + + + +
-
+ +
+ +
+ + + +
ACL Rule Matching @@ -839,51 +1328,51 @@ acl permission {||"all"} {action|"all"} [object|"all" The following illustration shows how ACL rules are processed to find matching rules. @@ -892,38 +1381,38 @@ acl permission {||"all"} {action|"all"} [object|"all"
Specifying ACL Permissions - Now that we have seen the ACL syntax, we will provide representative examples and guidelines for ACL files. + Now that we have seen the ACL syntax, we will provide representative examples and guidelines for ACL files. Most ACL files begin by defining groups: -group admin ted@QPID martin@QPID -group user-consume martin@QPID ted@QPID -group group2 kim@QPID user-consume rob@QPID -group publisher group2 \ -tom@QPID andrew@QPID debbie@QPID + group admin ted@QPID martin@QPID + group user-consume martin@QPID ted@QPID + group group2 kim@QPID user-consume rob@QPID + group publisher group2 \ + tom@QPID andrew@QPID debbie@QPID Rules in an ACL file grant or deny specific permissions to users or groups: -acl allow carlt@QPID create exchange name=carl.* -acl allow rob@QPID create queue -acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.rht.# -acl allow user-consume create queue name=tmp.* - -acl allow publisher publish all durable=false -acl allow publisher create queue name=RequestQueue -acl allow consumer consume queue durable=true -acl allow fred@QPID create all -acl allow bob@QPID all queue -acl allow admin all -acl allow all consume queue -acl allow all bind exchange -acl deny all all + acl allow carlt@QPID create exchange name=carl.* + acl allow rob@QPID create queue + acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.rht.# + acl allow user-consume create queue name=tmp.* + + acl allow publisher publish all durable=false + acl allow publisher create queue name=RequestQueue + acl allow consumer consume queue durable=true + acl allow fred@QPID create all + acl allow bob@QPID all queue + acl allow admin all + acl allow all consume queue + acl allow all bind exchange + acl deny all all In the previous example, the last line, acl deny all all, denies all authorizations that have not been specifically granted. This is the default, but it is useful to include it explicitly on the last line for the sake of clarity. If you want to grant all rights by default, you can specify acl allow all all in the last line. @@ -933,10 +1422,10 @@ acl deny all all -group users alice@QPID bob@QPID charlie@QPID -acl deny charlie@QPID create queue -acl allow users create queue -acl deny all all + group users alice@QPID bob@QPID charlie@QPID + acl deny charlie@QPID create queue + acl allow users create queue + acl deny all all @@ -947,42 +1436,74 @@ acl deny all all -group allUsers guest@QPID -.... -acl deny-log allUsers create link -acl deny-log allUsers access method name=connect -acl deny-log allUsers access method name=echo -acl allow all all + group allUsers guest@QPID + ... + acl deny-log allUsers create link + acl deny-log allUsers access method name=connect + acl deny-log allUsers access method name=echo + acl allow all all
- -
- Specifying ACL Connection Limits - - The ACL module creates two broker command line switches that set limits on the number of connections allowed per user or per client host address. These settings are not specified in the ACL file. - - - ---acl-max-connect-per-user N_USER ---acl-max-connect-per-ip N_IP - - - - If either of these switches is not specified or the value specified is zero then the corresponding connection limit is not enforced. - - - If a limit is set for user connections then all users are limited to that number of connections regardless of the client IP address the users are coming from. - - - If a limit is set for IP connections then connections for a given IP address are limited regardless of the user credentials presented with the connection. - - - Note that addresses using different transports are counted separately even though the host is actually the same physical machine. In the setting illustrated above a host would allow N_IP connections from [::1] IPv6 transport localhost and another N_IP connections from [127.0.0.1] IPv4 transport localhost. - -
- -
+ + +
+ User Connection and Queue Quotas + The ACL module enforces various quotas and thereby limits user activity. + +
+ Connection Limits + + The ACL module creates broker command line switches that set limits on the number of concurrent connections allowed per user or per client host address. These settings are not specified in the ACL file. + + + + --max-connections N + --max-connections-per-user N + --max-connections-per-ip N + + + + If a switch is not specified or the value specified is zero then the corresponding connection limit is not enforced. + + + max-connections specifies an upper limit for all user connections. + + + max-connections-per-user specifies an upper limit for each user based on the authenticated user name. This limit is enforced regardless of the client IP address from which the connection originates. + + + max-connections-per-ip specifies an upper limit for connections for all users based on the originating client IP address. This limit is enforced regardless of the user credentials presented with the connection. + + + Note that addresses using different transports are counted separately even though the originating host is actually the same physical machine. In the setting illustrated above a host would allow N_IP connections from [::1] IPv6 transport localhost and another N_IP connections from [127.0.0.1] IPv4 transport localhost. + + + The max-connections-per-ip and max-connections-per-user counts are active simultaneously. From a given client system users may be denied access to the broker by either connection limit. + + + +
+ +
+ Queue Limits + + The ACL module creates a broker command line switch that set limits on the number of queues each user is allowed to create. This settings is not specified in the ACL file. + + + + --max-queues-per-user N + + + + If this switch is not specified or the value specified is zero then the queue limit is not enforced. + + + The queue limit is set for all users on the broker based on the authenticated user name. + +
+ +
Encryption using SSL diff --git a/doc/book/src/java-broker/AMQP-Messaging-Broker-Java-Book.xml b/doc/book/src/java-broker/AMQP-Messaging-Broker-Java-Book.xml index 54c2984d0a..b2dbd969bc 100644 --- a/doc/book/src/java-broker/AMQP-Messaging-Broker-Java-Book.xml +++ b/doc/book/src/java-broker/AMQP-Messaging-Broker-Java-Book.xml @@ -8,66 +8,33 @@ 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. - ---> - - - AMQP Messaging Broker (Implemented in Java) - - Introduction - Qpid provides two AMQP messaging brokers: - - - Implemented in C++ - high performance, low latency, and RDMA support. - Implemented in Java - Fully JMS compliant, runs on any Java platform. - - - Both AMQP messaging brokers support clients in multiple languages, as long as the messaging client and the messaging broker use the same version of AMQP. - - This manual contains information specific to the broker that is implemented in Java. - - - - General User Guides - - - - - - - - - - -How Tos - - - - - - - - - - - - - +--> - + +AMQP Messaging Broker (Java) + + + + + + + + + + + + + + - -Management Tools - - diff --git a/doc/book/src/java-broker/Add-New-Users.xml b/doc/book/src/java-broker/Add-New-Users.xml deleted file mode 100644 index dc34bcc5c9..0000000000 --- a/doc/book/src/java-broker/Add-New-Users.xml +++ /dev/null @@ -1,237 +0,0 @@ - - - -
- Add New Users - - The Qpid Java Broker has a single reference source () that - defines all the users in the system. - - To add a new user to the broker the password file must be - updated. The details about adding entries and when these updates - take effect are dependent on the file format each of which are - described below. - - -
- Available - Password file formats - - - There are currently two different file formats available for use - depending on the PrincipalDatabase that is desired. In all cases - the clients need not be aware of the type of PrincipalDatabase in - use they only need support the SASL mechanisms they provide. - - - - - - - - - - - -
- Plain - - - The plain file has the following format: - - -# Plain password authentication file. -# default name : passwd -# Format <username>:<password> -#e.g. -martin:password - - - As the contents of the file are plain text and the password is - taken to be everything to the right of the ':'(colon). The - password, therefore, cannot contain a ':' colon, but this can be - used to delimit the password. - - Lines starting with a '#' are treated as comments. - -
- -
- Where is - the password file for my broker ? - - - The location of the password file in use for your broker is as - configured in your config.xml file. - - -<principal-databases> - <principal-database> - <name>passwordfile</name> - <class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class> - <attributes> - <attribute> - <name>passwordFile</name> - <value>${conf}/passwd</value> - </attribute> - </attributes> - </principal-database> - </principal-databases> - - - So in the example config.xml file this password file lives in the - directory specified as the conf directory (at the top of your - config.xml file). - - If you wish to use Base64 encoding for your password file, then - in the <class> element above you should specify - org.apache.qpid.server.security.auth.database.Base64MD5PasswordFilePrincipalDatabase - - The default is: - - - <conf>${prefix}/etc</conf> - -
- - -
- Base64MD5 - Password File Format - - - This format can be used to ensure that SAs cannot read the plain - text password values from your password file on disk. - - The Base64MD5 file uses the following format: - - -# Base64MD5 password authentication file -# default name : qpid.passwd -# Format <username>:<Base64 Encoded MD5 hash of the users password> -#e.g. -martin:X03MO1qnZdYdgyfeuILPmQ== - - - As with the Plain format the line is delimited by a ':'(colon). - The password field contains the MD5 Hash of the users password - encoded in Base64. - - This file is read on broker start-up and is not re-read. - -
- -
- How can - I update a Base64MD5 password file ? - - - To update the file there are two options: - - Edit the file by hand using the qpid-passwd tool - that will generate the required lines. The output from the tool - is the text that needs to be copied in to your active password - file. This tool is located in the broker bin directory. - Eventually it is planned for this tool to emulate the - functionality of - for qpid passwd files. - NOTE: For the changes to be seen by the broker you must - either restart the broker or reload the data with the - management tools (see ) - - Use the management tools to create a new user. The changes - will be made by the broker to the password file and the new user - will be immediately available to the system (see ). - - -
-
- - -
- Dynamic - changes to password files. - - - The Plain password file and the Base64MD5 format file are both - only read once on start up. - - To make changes dynamically there are two options, both require - administrator access via the Management Console (see ) - - You can replace the file and use the console to reload its - contents. - - The management console provides an interface to create, - delete and amend the users. These changes are written back to the - active password file. - - -
- -
- How password files and PrincipalDatabases relate to - authentication mechanisms - - - For each type of password file a PrincipalDatabase exists that - parses the contents. These PrincipalDatabases load various SASL - mechanism based on their supportability. e.g. the Base64MD5 file - format can't support Plain authentication as the plain password - is not available. Any client connecting need only be concerned - about the SASL module they support and not the type of - PrincipalDatabase. So I client that understands CRAM-MD5 will - work correctly with a Plain and Base64MD5 PrincipalDatabase. - - File Format and Principal Database - - - - FileFormat/PrincipalDatabase - - - SASL - - - - - Plain - - - AMQPLAIN PLAIN CRAM-MD5 - - - - - Base64MD5 - - - CRAM-MD5 CRAM-MD5-HASHED - - - -
- For details of SASL support see - -
- -
diff --git a/doc/book/src/java-broker/Broker-Configuration-Guide.xml b/doc/book/src/java-broker/Broker-Configuration-Guide.xml deleted file mode 100644 index 558d17c63c..0000000000 --- a/doc/book/src/java-broker/Broker-Configuration-Guide.xml +++ /dev/null @@ -1,28 +0,0 @@ - - - -
- Broker Configuration Guide - - - -
diff --git a/doc/book/src/java-broker/Configure-ACLs.xml b/doc/book/src/java-broker/Configure-ACLs.xml deleted file mode 100644 index e82f2a86d0..0000000000 --- a/doc/book/src/java-broker/Configure-ACLs.xml +++ /dev/null @@ -1,441 +0,0 @@ - - - - -
- - Configuring ACLs - - - In Qpid, ACLs specify which actions can be performed by each authenticated user. To enable the ACL <acl/> element is used within the - <security/> element of the configuration XML. In the Java Broker, the ACL may be imposed broker wide or applied to individual virtual - hosts. The <acl/> references a text file containing the ACL rules. By convention, this file should have a .acl extension. - - - -
- - Enabling ACLs - - - - To apply an ACL broker-wide, add the following to the config.xml (Assuming that conf has been set to a suitable - location such as ${QPID_HOME}/etc) - - - - <broker> - ... - <security> - ... - <acl>${conf}/broker.acl</acl> - </security> - </broker> - - - - - - - To apply an ACL on a single virtualhost named test, add the following to the config.xml: - - - - <virtualhost> - ... - <name>test</name> - <test> - ... - <security> - <acl>${conf}/vhost_test.acl</acl> - </security> - </test> - </virtualhost> - -
- -
- - Writing .acl files - - - - The ACL file consists of a series of rules and group definitions. Each rule grants or denies specific rights to a user or group. Group - definitions declare groups of users and serve to make the ACL file more concise. - - - Each ACL rule grants (or denies) a particular action on a object to a user. The rule may be augmented with one or more properties, restricting - the rule's applicability. - - - ACL ALLOW alice CREATE QUEUE # Grants alice permission to create all queues. - ACL DENY bob CREATE QUEUE name="myqueue" # Denies bob permission to create a queue called "myqueue" - - - The ACL is considered in strict line order with the first matching rule taking precedence over all those that follow. In the following - example, if the user bob tries to create an exchange "myexch", the operation will be allowed by the first rule. The second rule will - never be considered. - - - ACL ALLOW bob ALL EXCHANGE - ACL DENY bob CREATE EXCHANGE name="myexch" # Dead rule - - - If the desire is to allow bob to create all exchanges except "myexch", order of the rules must be reversed: - - - ACL DENY bob CREATE EXCHANGE name="myexch" - ACL ALLOW bob ALL EXCHANGE - - - All ACL files end with a implict rule denying all operations to all users. It is as if each file ends with - ACL DENY ALL ALL - To allow all operations, other than those controlled by earlier use ACL ALLOW ALL ALL instead. - - - When writing a new ACL, a good approach is to begin with an .acl file containing only ACL DENY-LOG ALL ALL - which will cause the Broker to deny all operations with details of the denial logged to the Qpid log file. Build up the ACL rule by rule, - gradually working through the use-cases of your system. Once the ACL is complete, switch the DEBY-LOG to DENY for optimum performamce. - - - ACL rules are very powerful: it is possible to write very expressive rules permissioning every AMQP objects enumerating all object - properties. Most projects probably won't need this degree of flexibility. A reasonable approach is to choose to apply permissions - at a certain level of abstraction (i.e. QUEUE) and apply consistently across the whole system. - -
- -
- - Syntax - - - - ACL rules must follow this syntax: - - - ACL {permission} {<group-name>|<user-name>>|ALL} {action|ALL} [object|ALL] [property="<property-value>"] - - - - GROUP definitions must follow this syntax: - - - GROUP {group name} {username 1}..{username n} # Where username is a username, or a groupname. - - - - Comments may be introduced with the hash (#) character and are ignored. Long lines can be broken with the slash (\) character. - - - # A comment - ACL ALLOW admin CREATE ALL # Also a comment - ACL DENY guest \ - ALL ALL # A broken line - GROUP securegroup bob \ - alice # Another broker line - -
- - ACL Rules: permission - - - - ALLOW - Allow the action - - - ALLOW-LOG - Allow the action and log the action in the log - - - DENY - Deny the action - - - DENY-LOG - Deny the action and log the action in the log - - - -
- - ACL Rules:action - - - - CONSUME - Applied when subscriptions are created - - - PUBLISH - Applied on a per message basis on publish message transfers - - - CREATE - Applied when an object is created, such as bindings, queues, exchanges - - - ACCESS - Applied when an object is read or accessed - - - BIND - Applied when queues are bound to exchanges - - - UNBIND - Applied when queues are unbound from exchanges - - - DELETE - Applied when objects are deleted - - - PURGE - Applied when purge the contents of a queue - - - UPDATE - Applied when an object is updated - - - -
- - ACL Rules:object - - - - QUEUE - A queue - - - EXCHANGE - An exchange - - - VIRTUALHOST - A virtualhost (Java Broker only) - - - METHOD - Management or agent or broker method (Java Broker only) - - - BROKER - The broker (not currently used in Java Broker) - - - LINK - A federation or inter-broker link (not currently used in Java Broker) - - - -
- - ACL Rules:property - - - - name - String. Object name, such as a queue name, exchange name or JMX method name. - - - durable - Boolean. Indicates the object is durable - - - routingkey - String. Specifies routing key - - - passive - Boolean. Indicates the presence of a passive flag - - - autodelete - Boolean. Indicates whether or not the object gets deleted when the connection is closed - - - exclusive - Boolean. Indicates the presence of an exclusive flag - - - temporary - Boolean. Indicates the presence of an temporary flag - - - type - String. Type of object, such as topic, fanout, or xml - - - alternate - String. Name of the alternate exchange - - - queuename - String. Name of the queue (used only when the object is something other than queue - - - component - String. JMX component name (Java Broker only) - - - schemapackage - String. QMF schema package name (Not used in Java Broker) - - - schemaclass - String. QMF schema class name (Not used in Java Broker) - - - -
- - ACL rules:components (Java Broker only) - - - - UserManagement - User maintainance; create/delete/view users, change passwords etc - permissionable at broker level only - - - ConfigurationManagement - Dynammically reload configuration from disk. - permissionable at broker level only - - - LoggingManagement - Dynammically control Qpid logging level - permissionable at broker level only - - - ServerInformation - Read-only information regarding the Qpid: version number etc - permissionable at broker level only - - - VirtualHost.Queue - Queue maintainance; copy/move/purge/view etc - - - VirtualHost.Exchange - Exchange maintenance; bind/unbind queues to exchanges - - - VirtualHost.VirtualHost - Virtual host maintainace; create/delete exchanges, queues etc - - - -
-
- - Worked Examples - - - Here are three example ACLs illustrating some common use-cases. - -
- - Worked example 1 - Management rights - - - Suppose you wish to permission two users: a user 'operator' must be able to perform all Management operations, and - a user 'readonly' must be enable to perform only read-only functions. Neither 'operator' nor 'readonly' - should be allow to connect for messaging. - - - # Give operator permission to execute all JMX Methods - ACL ALLOW operator ALL METHOD - # Give operator permission to execute only read-only JMX Methods - ACL ALLOW readonly ACCESS METHOD - # Deny operator/readonly permission to perform messaging. - ACL DENY operator ACCESS VIRTUALHOST - ACL DENY readonly ACCESS VIRTUALHOST - ... - ... rules for other users - ... - # Explicitly deny all (log) to eveyone - ACL DENY-LOG ALL ALL - -
-
- - Worked example 2 - User maintainer group - - - Suppose you wish to restrict User Management operations to users belonging to a group 'usermaint'. No other user - is allowed to perform user maintainence This example illustrates the permissioning of a individual component - and a group definition. - - - # Create a group usermaint with members bob and alice - GROUP usermaint bob alice - # Give operator permission to execute all JMX Methods - ACL ALLOW usermaint ALL METHOD component="UserManagement" - ACL DENY ALL ALL METHOD component="UserManagement" - ... - ... rules for other users - ... - ACL DENY-LOG ALL ALL - -
-
- - Worked example 3 - Request/Response messaging - - - Suppose you wish to permission a system using a request/response paradigm. Two users: 'client' publishes requests; - 'server' consumes the requests and generates a response. This example illustrates the permissioning of AMQP exchanges - and queues. - - - # Allow client and server to connect to the virtual host. - ACL ALLOW client ACCESS VIRTUALHOST - ACL ALLOW server ACCESS VIRTUALHOST - - # Client side - # Allow the 'client' user to publish requests to the request queue. As is the norm for the request/response paradigm, the client - # is required to create a temporary queue on which the server will response. Consequently, there are rules to allow the creation - # of the temporary queues and consumption of messages from it. - ACL ALLOW client CREATE QUEUE temporary="true" - ACL ALLOW client CONSUME QUEUE temporary="true" - ACL ALLOW client DELETE QUEUE temporary="true" - ACL ALLOW client BIND EXCHANGE name="amq.direct" temporary="true" - ACL ALLOW client UNBIND EXCHANGE name="amq.direct" temporary="true" - ACL ALLOW client PUBLISH EXCHANGE name="amq.direct" routingKey="example.RequestQueue" - - # Server side - # Allow the 'server' user to consume from the request queue and publish a response to the temporary response queue created by - # client. We also allow the server to create the request queue. - ACL ALLOW server CREATE QUEUE name="example.RequestQueue" - ACL ALLOW server CONSUME QUEUE name="example.RequestQueue" - ACL ALLOW server BIND EXCHANGE - ACL ALLOW server PUBLISH EXCHANGE name="amq.direct" routingKey="TempQueue*" - - ACL DENY-LOG all all - -
-
-
diff --git a/doc/book/src/java-broker/Configure-Java-Qpid-to-use-a-SSL-connection.xml b/doc/book/src/java-broker/Configure-Java-Qpid-to-use-a-SSL-connection.xml deleted file mode 100644 index 838b899337..0000000000 --- a/doc/book/src/java-broker/Configure-Java-Qpid-to-use-a-SSL-connection.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
- Configure Java Qpid to use a SSL connection. - - -
- Using SSL connection with Qpid Java. - - - This section will show how to use SSL to enable secure - connections between a Java client and broker. - -
-
- Setup - -
- Broker - Setup - - - The broker configuration file (config.xml) needs to be updated to - include the SSL keystore location details. - - - -<!-- Additions required to Connector Section --> - -<ssl> - <enabled>true</enabled> - <sslOnly>true</sslOnly> - <keyStorePath>/path/to/keystore.ks</keyStorePath> - <keyStorePassword>keystorepass</keyStorePassword> -</ssl> - - - - The sslOnly option is included here for completeness however this - will disable the unencrypted port and leave only the SSL port - listening for connections. - -
-
- Client - Setup - - - The best place to start looking is class - SSLConfiguration this is provided to the connection - during creation however there is currently no example that - demonstrates its use. - -
-
- -
- Performing - the connection. - - -
-
diff --git a/doc/book/src/java-broker/Configure-Log4j-CompositeRolling-Appender.xml b/doc/book/src/java-broker/Configure-Log4j-CompositeRolling-Appender.xml deleted file mode 100644 index f52bc55399..0000000000 --- a/doc/book/src/java-broker/Configure-Log4j-CompositeRolling-Appender.xml +++ /dev/null @@ -1,150 +0,0 @@ - - - - -
- Configure Log4j CompositeRolling Appender - -
- How to configure the CompositeRolling log4j Appender - - - There are several sections of our default log4j file that will - need your attention if you wish to fully use this Appender. - - - - - Enable the Appender - - The default log4j.xml file uses the FileAppender, swap this for - the ArchivingFileAppender as follows: - - - <!-- Log all info events to file --> - <root> - <priority value="info"/> - - <appender-ref ref="ArchivingFileAppender"/> - </root> - - - - - Configure the Appender - - - - The Appender has a number of parameters that can be adjusted - depending on what you are trying to achieve. For clarity lets - take a quick look at the complete default appender: - - - <appender name="ArchivingFileAppender" class="org.apache.log4j.QpidCompositeRollingAppender"> - <!-- Ensure that logs allways have the dateFormat set--> - <param name="StaticLogFileName" value="false"/> - <param name="File" value="${QPID_WORK}/log/${logprefix}qpid${logsuffix}.log"/> - <param name="Append" value="false"/> - <!-- Change the direction so newer files have bigger numbers --> - <!-- So log.1 is written then log.2 etc This prevents a lot of file renames at log rollover --> - <param name="CountDirection" value="1"/> - <!-- Use default 10MB --> - <!--param name="MaxFileSize" value="100000"/--> - <param name="DatePattern" value="'.'yyyy-MM-dd-HH-mm"/> - <!-- Unlimited number of backups --> - <param name="MaxSizeRollBackups" value="-1"/> - <!-- Compress(gzip) the backup files--> - <param name="CompressBackupFiles" value="true"/> - <!-- Compress the backup files using a second thread --> - <param name="CompressAsync" value="true"/> - <!-- Start at zero numbered files--> - <param name="ZeroBased" value="true"/> - <!-- Backup Location --> - <param name="backupFilesToPath" value="${QPID_WORK}/backup/log"/> - - <layout class="org.apache.log4j.PatternLayout"> - <param name="ConversionPattern" value="%d %-5p [%t] %C{2} (%F:%L) - %m%n"/> - </layout> - </appender> - - - The appender configuration has three groups of parameter - configuration. - - The first group is for configuration of the file name. The - default is to write a log file to QPID_WORK/log/qpid.log - (Remembering you can use the logprefix and logsuffix values to - modify the file name, see Property Config). - - - <!-- Ensure that logs always have the dateFormat set--> - <param name="StaticLogFileName" value="false"/> - <param name="File" value="${QPID_WORK}/log/${logprefix}qpid${logsuffix}.log"/> - <param name="Append" value="false"/> - - - The second section allows the specification of a Maximum File - Size and a DatePattern that will be used to move on to the next - file. - - When MaxFileSize is reached a new log file will be created - The DataPattern is used to decide when to create a new log file, - so here a new file will be created for every minute and every - 10Meg of data. So if 15MB of data is made every minute then there - will be two log files created each minute. One at the start of - the minute and a second when the file hit 10MB. When the next - minute arrives a new file will be made even though it only has - 5MB of content. For a production system it would be expected to - be changed to something like 'yyyy-MM-dd' which would make a new - log file each day and keep the files to a max of 10MB. - - The final MaxSizeRollBackups allows you to limit the amount of - disk you are using by only keeping the last n backups. - - - <!-- Change the direction so newer files have bigger numbers --> - <!-- So log.1 is written then log.2 etc This prevents a lot of file renames at log rollover --> - <param name="CountDirection" value="1"/> - <!-- Use default 10MB --> - <!--param name="MaxFileSize" value="100000"/--> - <param name="DatePattern" value="'.'yyyy-MM-dd-HH-mm"/> - <!-- Unlimited number of backups --> - <param name="MaxSizeRollBackups" value="-1"/> - - - The final section allows the old log files to be compressed and - copied to a new location. - - - <!-- Compress(gzip) the backup files--> - <param name="CompressBackupFiles" value="true"/> - <!-- Compress the backup files using a second thread --> - <param name="CompressAsync" value="true"/> - <!-- Start at zero numbered files--> - <param name="ZeroBased" value="true"/> - <!-- Backup Location --> - <param name="backupFilesToPath" value="${QPID_WORK}/backup/log"/> - - - -
-
diff --git a/doc/book/src/java-broker/Configure-the-Broker-via-config.xml.xml b/doc/book/src/java-broker/Configure-the-Broker-via-config.xml.xml deleted file mode 100644 index 6a7729acd8..0000000000 --- a/doc/book/src/java-broker/Configure-the-Broker-via-config.xml.xml +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
- - Configure the Broker via config.xml - -
- - Broker config.xml Overview - - - The broker config.xml file which is shipped in the etc directory - of any Qpid binary distribution details various options and - configuration for the Java Qpid broker implementation. - - - In tandem with the virtualhosts.xml file, the config.xml file - allows you to control much of the deployment detail for your Qpid - broker in a flexible fashion. - - - Note that you can pass the config.xml you wish to use for your - broker instance to the broker using the -c command line option. - In turn, you can specify the paths for the broker password file - and virtualhosts.xml files in your config.xml for simplicity. - - - For more information about command line configuration options - please see . - - -
- -
- - Qpid - Version - - - The config format has changed between versions here you can find - the configuration details on a per version basis. - - - - - - -
- -
diff --git a/doc/book/src/java-broker/Configure-the-Virtual-Hosts-via-virtualhosts.xml.xml b/doc/book/src/java-broker/Configure-the-Virtual-Hosts-via-virtualhosts.xml.xml deleted file mode 100644 index 804970b923..0000000000 --- a/doc/book/src/java-broker/Configure-the-Virtual-Hosts-via-virtualhosts.xml.xml +++ /dev/null @@ -1,131 +0,0 @@ - - - - -
- Configure the Virtual Hosts via virtualhosts.xml -
- virtualhosts.xml Overview - - - This configuration file contains details of all queues and - topics, and associated properties, to be created on broker - startup. These details are configured on a per virtual host - basis. - - Note that if you do not add details of a queue or topic you - intend to use to this file, you must first create a consumer on a - queue/topic before you can publish to it using Qpid. - - Thus most application deployments need a virtualhosts.xml file - with at least some minimal detail. - - -
- XML Format with Comments - - - The virtualhosts.xml which currently ships as part of the Qpid - distribution is really targeted at development use, and supports - various artifacts commonly used by the Qpid development team. - - As a result, it is reasonably complex. In the example XML below, - I have tried to simplify one example virtual host setup which is - possibly more useful for new users of Qpid or development teams - looking to simply make use of the Qpid broker in their - deployment. - - I have also added some inline comments on each section, which - should give some extra information on the purpose of the various - elements. - - - - - -<virtualhosts> - <!-- Sets the default virtual host for connections which do not specify a vh --> - <default>localhost</default> - <!-- Define a virtual host and all it's config --> - <virtualhost> - <name>localhost</name> - <localhost> - <!-- Define the types of additional AMQP exchange available for this vh --> - <!-- Always get amq.direct (for queues) and amq.topic (for topics) by default --> - <exchanges> - <!-- Example of declaring an additional exchanges type for developer use only --> - <exchange> - <type>direct</type> - <name>test.direct</name> - <durable>true</durable> - </exchange> - </exchanges> - - <!-- Define the set of queues to be created at broker startup --> - <queues> - <!-- The properties configured here will be applied as defaults to all --> - <!-- queues subsequently defined unless explicitly overridden --> - <exchange>amq.direct</exchange> - <!-- Set threshold values for queue monitor alerting to log --> - <maximumQueueDepth>4235264</maximumQueueDepth> <!-- 4Mb --> - <maximumMessageSize>2117632</maximumMessageSize> <!-- 2Mb --> - <maximumMessageAge>600000</maximumMessageAge> <!-- 10 mins --> - - <!-- Define a queue with all default settings --> - <queue> - <name>ping</name> - </queue> - <!-- Example definitions of queues with overriden settings --> - <queue> - <name>test-queue</name> - <test-queue> - <exchange>test.direct</exchange> - <durable>true</durable> - </test-queue> - </queue> - <queue> - <name>test-ping</name> - <test-ping> - <exchange>test.direct</exchange> - </test-ping> - </queue> - </queues> - </localhost> - </virtualhost> -</virtualhosts> - -
-
- Using your own virtualhosts.xml - - - - Note that the config.xml file shipped as an example (or developer - default) in the Qpid distribution contains an element which - defines the path to the virtualhosts.xml. - - When using your own virtualhosts.xml you must edit this path to - point at the location of your file. - -
-
-
diff --git a/doc/book/src/java-broker/Configuring-Management-Users.xml b/doc/book/src/java-broker/Configuring-Management-Users.xml deleted file mode 100644 index a2a8d46d88..0000000000 --- a/doc/book/src/java-broker/Configuring-Management-Users.xml +++ /dev/null @@ -1,117 +0,0 @@ - - - - -
- Configuring Management Users - - The Qpid Java broker has a single source of users for the system. - So a user can connect to the broker to send messages and via the - JMX console to check the state of the broker. - - - - -
- Adding - a new management user - - - The broker does have some minimal configuration available to - limit which users can connect to the JMX console and what they - can do when they are there. - - There are two steps required to add a new user with rights for - the JMX console. - - Create a new user login, see HowTo: - - Grant the new user permission to the JMX Console - - - -
- Granting - JMX Console Permissions - - - By default new users do not have access to the JMX console. The - access to the console is controlled via the file - jmxremote.access. - - This file contains a mapping from user to privilege. - - There are three privileges available: - - readonly - The user is able to log in and view queues but not - make any changes. - - readwrite - Grants user ability to read and write queue - attributes such as alerting values. - - admin - Grants the user full access including ability to edit - Users and JMX Permissions in addition to readwrite access. - - - This file is read at start up and can forcibly be reloaded by an - admin user through the management console. - -
- -
- Access - File Format - - - The file is a standard Java properties file and has the following - format - - -<username>=<privilege> - - - If the username value is not a valid user (list in the specified - PrincipalDatabase) then the broker will print a warning when it - reads the file as that entry will have no meaning. - - Only when the the username exists in both the access file and the - PrincipalDatabase password file will the user be able to login - via the JMX Console. -
- Example File - - - The file will be timestamped by the management console if edited - through the console. - - -#Generated by JMX Console : Last edited by user:admin -#Tue Jun 12 16:46:39 BST 2007 -admin=admin -guest=readonly -user=readwrite - - -
-
-
-
diff --git a/doc/book/src/java-broker/Configuring-Qpid-JMX-Management-Console.xml b/doc/book/src/java-broker/Configuring-Qpid-JMX-Management-Console.xml deleted file mode 100644 index 72e4ba8969..0000000000 --- a/doc/book/src/java-broker/Configuring-Qpid-JMX-Management-Console.xml +++ /dev/null @@ -1,181 +0,0 @@ - - - - -
- Configuring Qpid JMX Management Console -
- Configuring Qpid JMX Management Console - - - - Qpid has a JMX management interface that exposes a number of - components of the running broker. - You can find out more about the features exposed by the JMX - interfaces . - - - - -
- Installing the Qpid JMX Management Console - - - - Unzip the archive to a suitable location. - - SSL encrypted connections - - Recent versions of the broker can make use of SSL to - encrypt their RMI based JMX connections. If a broker - being connected to is making use of this ability then - additional console configuration may be required, - particularly when using self-signed certificates. See - for details. - - - - - - - JMXMP based connections - - In previous releases of Qpid (M4 and below) the broker - JMX connections could make use of the JMXMPConnector for - additional security over its default RMI based JMX - configuration. This is no longer the case, with SSL - encrypted RMI being the favored approach going forward. - However, if you wish to connect to an older broker using - JMXMP the console will support this so long as the - jmxremote_optional.jar file is provided to it. - For details see . - - -
- - -
- Running the Qpid JMX Management Console - - - - The console can be started in the following way, depending on - platform: - - Windows: by running the 'qpidmc.exe' executable file. - - - Linux: by running the 'qpidmc' executable. - - - Mac OS X: by launching the consoles application bundle (.app - file). - - -
- - -
- Using the Qpid JMX Management Console - - - - Please see for details on using this Eclipse RCP - application. - - -
-
- -
- Using - JConsole - - - - See - -
- - -
- Using - HermesJMS - - - - HermesJMS also offers integration with the Qpid management - interfaces. You can get instructions and more information from - HermesJMS. - -
- -
- Using - MC4J - - - - MC4J is an alternative - management tool. It provide a richer "dashboard" that can - customise the raw MBeans. - -
- Installation - - - - First download and install MC4J for your platform. Version - 1.2 beta 9 is the latest version that has been tested. - - Copy the directory blaze/java/management/mc4j into - the directory <MC4J-Installation>/dashboards - - -
- -
- Configuration - - - - You should create a connection the JVM to be managed. Using the - Management->Create Server Connection menu option. The - connection URL should be of the form: - service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi - making the appropriate host and post changes. - -
- -
- Operation - - - - You can view tabular summaries of the queues, exchanges and - connections using the Global Dashboards->QPID tree view. To - drill down on individual beans you can right click on the bean. - This will show any available graphs too. - -
-
-
diff --git a/doc/book/src/java-broker/Debug-using-log4j.xml b/doc/book/src/java-broker/Debug-using-log4j.xml deleted file mode 100644 index 615fd9e560..0000000000 --- a/doc/book/src/java-broker/Debug-using-log4j.xml +++ /dev/null @@ -1,298 +0,0 @@ - - - - -
- Debug using log4j - - -
- Debugging - with log4j configurations - - - Unfortunately setting of logging in the Java Broker is not simply - a matter of setting one of WARN,INFO,DEBUG. At some point in the - future we may have more BAU logging that falls in to that - category but more likely is that we will have a varioius config - files that can be swapped in (dynamically) to understand what is - going on. - - This page will be host to a variety of useful configuration - setups that will allow a user or developer to extract only the - information they are interested in logging. Each section will be - targeted at logging in a particular area and will include a full - log4j file that can be used. In addition the logging - category elements will be presented and discussed so - that the user can create their own file. - - Currently the configuration that is available has not been fully - documented and as such there are gaps in what is desired and what - is available. Some times this is due to the desire to reduce the - overhead in message processing, but sometimes it is simply an - oversight. Hopefully in future releases the latter will be - addressed but care needs to be taken when adding logging to the - 'Message Flow' path as this will have performance implications. - - -
- Logging - Connection State *Deprecated* - - - deprecation notice Version 0.6 of the Java broker includes - functionality which improves upon these messages and - as such enabling status logging would be more beneficial. - The configuration file has been left here for assistence with - broker versions prior to 0.6. - - The goals of this configuration are to record: - - New Connections - - New Consumers - - Identify slow consumers - - Closing of Consumers - - Closing of Connections - - - An additional goal of this configuration is to minimise any - impact to the 'message flow' path. So it should not adversely - affect production systems. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -]]> - -
- -
- Debugging My - Application - - - This is the most often asked for set of configuration. The goals - of this configuration are to record: - - New Connections - - New Consumers - - Message Publications - - Message Consumption - - Identify slow consumers - - Closing of Consumers - - Closing of Connections - - - NOTE: This configuration enables message logging on the 'message - flow' path so should only be used were message volume is - low. - Every message that is sent to the broker will generate at - least four logging statements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -]]> - - -
-
-
diff --git a/doc/book/src/java-broker/HA-Guide.xml b/doc/book/src/java-broker/HA-Guide.xml deleted file mode 100644 index 041309d711..0000000000 --- a/doc/book/src/java-broker/HA-Guide.xml +++ /dev/null @@ -1,1008 +0,0 @@ - - - - - - -]> - -
- High Availability - -
- General Introduction - The term High Availability (HA) usually refers to having a number of instances of a service such as a Message Broker - available so that should a service unexpectedly fail, or requires to be shutdown for maintenance, users may quickly connect - to another instance and continue their work with minimal interuption. HA is one way to make a overall system more resilient - by eliminating a single point of failure from a system. - HA offerings are usually categorised as Active/Active or Active/Passive. - An Active/Active system is one where all nodes within the cluster are usuaully available for use by clients all of the time. In an - Active/Passive system, one only node within the cluster is available for use by clients at any one time, whilst the others are in - some kind of standby state, awaiting to quickly step-in in the event the active node becomes unavailable. - -
- -
- HA offerings of the Java Broker - The Java Broker's HA offering became available at release 0.18. HA is provided by way of the HA - features built into the Java Edition of the Berkley Database (BDB JE) and as such - is currently only available to Java Broker users who use the optional BDB JE based persistence store. This - optional store requires the use of BDB JE which is licensed under the Sleepycat Licence, which is - not compatible with the Apache Licence and thus BDB JE is not distributed with Qpid. Users who elect to use this optional store for - the broker have to provide this dependency. - HA in the Java Broker provides an Active/Passive mode of operation with Virtual hosts being - the unit of replication. The Active node (referred to as the Master) accepts all work from all the clients. - The Passive nodes (referred to as Replicas) are unavailable for work: the only task they must perform is - to remain in synch with the Master node by consuming a replication stream containing all data and state. - If the Master node fails, a Replica node is elected to become the new Master node. All clients automatically failover - The automatic failover feature is available only for AMQP connections from the Java client. Management connections (JMX) - do not current offer this feature. to the new Master and continue their work. - The Java Broker HA solution is incompatible with the HA solution offered by the CPP Broker. It is not possible to co-locate Java and CPP - Brokers within the same cluster. - HA is not currently available for those using the the Derby Store or Memory - Message Store. -
- -
- Two Node Cluster -
- Overview - In this HA solution, a cluster is formed with two nodes. one node serves as - master and the other is a replica. - - All data and state required for the operation of the virtual host is automatically sent from the - master to the replica. This is called the replication stream. The master virtual host confirms each - message is on the replica before the client transaction completes. The exact way the client awaits - for the master and replica is gorverned by the durability - configuration, which is discussed later. In this way, the replica remains ready to take over the - role of the master if the master becomes unavailable. - - It is important to note that there is an inherent limitation of two node clusters is that - the replica node cannot make itself master automatically in the event of master failure. This - is because the replica has no way to distinguish between a network partition (with potentially - the master still alive on the other side of the partition) and the case of genuine master failure. - (If the replica were to elect itself as master, the cluster would run the risk of a - split-brain scenario). - In the event of a master failure, a third party must designate the replica as primary. This process - is described in more detail later. - - Clients connect to the cluster using a failover url. - This allows the client to maintain a connection to the master in a way that is transparent - to the client application. -
-
- Depictions of cluster operation - In this section, the operation of the cluster is depicted through a series of figures - supported by explanatory text. -
- Key for figures - - - - - - Key to figures - - -
-
- Normal Operation - The figure below illustrates normal operation. Clients connecting to the cluster by way - of the failover URL achieve a connection to the master. As clients perform work (message - production, consumption, queue creation etc), the master additionally sends this data to the - replica over the network. -
- Normal operation of a two-node cluster - - - - - - Normal operation - - -
-
-
- Master Failure and Recovery - The figure below illustrates a sequence of events whereby the master suffers a failure - and the replica is made the master to allow the clients to continue to work. Later the - old master is repaired and comes back on-line in replica role. - The item numbers in this list apply to the numbered boxes in the figure below. - - - System operating normally - - - Master suffers a failure and disconnects all clients. Replica realises that it is no - longer in contact with master. Clients begin to try to reconnect to the cluster, although these - connection attempts will fail at this point. - - - A third-party (an operator, a script or a combination of the two) verifies that the master has truely - failed and is no longer running. If it has truely failed, the decision is made - to designate the replica as primary, allowing it to assume the role of master despite the other node being down. - This primary designation is performed using JMX. - - - Client connections to the new master succeed and the service is restored - , albeit without a replica. - - - The old master is repaired and brought back on-line. It automatically rejoins the cluster - in the replica role. - - -
- Failure of master and recovery sequence - - - - - - Failure of master and subsequent recovery sequence - - -
-
-
- Replica Failure and Recovery - The figure that follows illustrates a sequence of events whereby the replica suffers a failure - leaving the master to continue processing alone. Later the replica is repaired and is restarted. - It rejoins the cluster so that it is once again ready to take over in the event of master failure. - The behavior of the replica failure case is governed by the designatedPrimary - configuration item. If set true on the master, the master will continue to operate solo without outside - intervention when the replica fails. If false, a third-party must designate the master as primary in order - for it to continue solo. - The item numbers in this list apply to the numbered boxes in the figure below. This example assumes - that designatedPrimary is true on the original master node. - - - System operating normally - - - Replica suffers a failure. Master realises that replica longer in contact but as - designatedPrimary is true, master continues processing solo and thus client - connections are uninterrupted by the loss of the replica. System continues operating normally, albeit - with a single node. - - - Replica is repaired. - - - After catching up with missed work, replica is once again ready to take over in the event of master failure. - - -
- Failure of replica and subsequent recovery sequence - - - - - - Failure of replica and subsequent recovery sequence - - -
-
-
- Network Partition and Recovery - The figure below illustrates the sequence of events that would occur if the network between - master and replica were to suffer a partition, and the nodes were out of contact with one and other. - As with Replica Failure and Recovery, the - behaviour is governed by the designatedPrimary. - Only if designatedPrimary is true on the master, will the master continue solo. - The item numbers in this list apply to the numbered boxes in the figure below. This example assumes - that designatedPrimary is true on the original master node. - - - System operating normally - - - Network suffers a failure. Master realises that replica longer in contact but as - designatedPrimary is true, master continues processing solo and thus client - connections are uninterrupted by the network partition between master and replica. - - - Network is repaired. - - - After catching up with missed work, replica is once again ready to take over in the event of master failure. - System operating normally again. - - -
- Partition of the network separating master and replica - - - - - - Network Partition and Recovery - - -
-
-
- Split Brain - A split-brain - is a situation where the two node cluster has two masters. BDB normally strives to prevent - this situation arising by preventing two nodes in a cluster being master at the same time. - However, if the network suffers a partition, and the third-party intervenes incorrectly - and makes the replica a second master a split-brain will be formed and both masters will - proceed to perform work independently of one and other. - There is no automatic recovery from a split-brain. - Manual intervention will be required to choose which store will be retained as master - and which will be discarded. Manual intervention will be required to identify and repeat the - lost business transactions. - The item numbers in this list apply to the numbered boxes in the figure below. - - - System operating normally - - - Network suffers a failure. Master realises that replica longer in contact but as - designatedPrimary is true, master continues processing solo. Client - connections are uninterrupted by the network partition. - A third-party erroneously designates the replica as primary while the - original master continues running (now solo). - - - As the nodes cannot see one and other, both behave as masters. Clients may perform work against - both master nodes. - - -
- Split Brain - - - - - - Split Brain - - -
-
-
-
- -
- Multi Node Cluster - Multi node clusters, that is clusters where the number of nodes is three or more, are not yet - ready for use. -
- -
- Configuring a Virtual Host to be a node - To configure a virtualhost as a cluster node, configure the virtualhost.xml in the following manner: - - - myhost - - - org.apache.qpid.server.store.berkeleydb.BDBHAMessageStore - ${work}/bdbhastore - - myclustername - mynode1 - node1host:port - node1host:port - NO_SYNC\,NO_SYNC\,SIMPLE_MAJORITY - true|false - true|false - - - ... - -]]> - - The groupName is the name of logical name of the cluster. All nodes within the - cluster must use the same groupName in order to be considered part of the cluster. - The nodeName is the logical name of the node. All nodes within the cluster must have a - unique name. It is recommended that the node name should be chosen from a different nomenclature from that of - the servers on which they are hosted, in case the need arises to move node to a new server in the future. - The nodeHostPort is the hostname and port number used by this node to communicate with the - the other nodes in the cluster. For the hostname, an IP address, hostname or fully qualified hostname may be used. - For the port number, any free port can be used. It is important that this address is stable over time, as BDB - records and uses this address internally. - The helperHostPort is the hostname and port number that new nodes use to discover other - nodes within the cluster when they are newly introduced to the cluster. When configuring the first node, set the - helperHostPort to its own nodeHostPort. For the second and subsequent nodes, - set their helperHostPort to that of the first node. - durability controls the durability - guarantees made by the cluster. It is important that all nodes use the same value for this property. The default value is - NO_SYNC\,NO_SYNC\,SIMPLE_MAJORITY. Owing to the internal use of Apache Commons Config, it is currently necessary - to escape the commas within the durability string. - coalescingSync controls the coalescing-sync - mode of Qpid. It is important that all nodes use the same value. If omitted, it defaults to true. - The designatedPrimary is applicable only to the two-node - case. It governs the behaviour of a node when the other node fails or becomes uncontactable. If true, - the node will be designated as primary at startup and will be able to continue operating as a single node master. - If false, the node will transition to an unavailable state until a third-party manually designates the node as - primary or the other node is restored. It is suggested that the node that normally fulfils the role of master is - set true in config file and the node that is normally replica is set false. Be aware that setting both nodes to - true will lead to a failure to start up, as both cannot be designated at the point of contact. Designating both - nodes as primary at runtime (using the JMX interface) will lead to a split-brain - in the case of network partition and must be avoided. - Usage of domain names in helperHostPort and nodeHostPort is more preferebale - over IP addresses due to the tendency of more frequent changes of the last over the former. - If server IP address changes but domain name remains the same the HA cluster can continue working as normal - in case when domain names are used in cluster configuration. In case when IP addresses are used and they are changed with the time - than Qpid JMX API for HA can be used to change the addresses or remove the nodes from the cluster. - -
- Passing BDB environment and replication configuration options - It is possible to pass BDB - environment and - replication configuration options from the virtualhost.xml. Environment configuration options are passed using - the envConfig element, and replication config using repConfig. - For example, to override the BDB environment configuration options je.cleaner.threads and - je.txn.timeout - - - je.cleaner.threads - 2 - - - je.txn.timeout - 15 min - - ... - ]]> - And to override the BDB replication configuration options je.rep.insufficientReplicasTimeout. - - ... - - je.rep.insufficientReplicasTimeout - 2 - - - je.txn.timeout - 10 s - - ... - ]]> -
-
- -
- Durability Guarantees - The term durability is used to mean that once a - transaction is committed, it remains committed regardless of subsequent failures. A highly durable system is one where - loss of a committed transaction is extermely unlikely, whereas with a less durable system loss of a transaction is likely - in a greater number of scenarios. Typically, the more highly durable a system the slower and more costly it will be. - Qpid exposes the all the - durability controls - offered by by BDB JE JA and a Qpid specific optimisation called coalescing-sync which defaults - to enabled. -
- BDB Durability Controls - BDB expresses durability as a triplet with the following form: - ,,]]> - The sync polices controls whether the thread performing the committing thread awaits the successful completion of the - write, or the write and sync before continuing. The master sync policy and replica sync policy need not be the same. - For master and replic sync policies, the available values are: - SYNC, - WRITE_NO_SYNC, - NO_SYNC. SYNC - is offers the highest durability whereas NO_SYNC the lowest. - Note: the combination of a master sync policy of SYNC and coalescing-sync - true would result in poor performance with no corresponding increase in durability guarantee. It cannot not be used. - The acknowledgement policy defines whether when a master commits a transaction, it also awaits for the replica(s) to - commit the same transaction before continuing. For the two-node case, ALL and SIMPLE_MAJORITY are equal. - For acknowledgement policy, the available value are: - ALL, - SIMPLE_MAJORITY - NONE. -
-
- Coalescing-sync - If enabled (the default) Qpid works to reduce the number of separate - file-system sync operations - performed by the master on the underlying storage device thus improving performance. It does - this coalescing separate sync operations arising from the different client commits operations occuring at approximately the same time. - It does this in such a manner not to reduce the ACID guarantees of the system. - Coalescing-sync has no effect on the behaviour of the replicas. -
-
- Default - The default durability guarantee is NO_SYNC, NO_SYNC, SIMPLE_MAJORITY with coalescing-sync enabled. The effect - of this combination is described in the table below. It offers a good compromise between durability guarantee and performance - with writes being guaranteed on the master and the additional guarantee that a majority of replicas have received the - transaction. -
-
- Examples - Here are some examples illustrating the effects of the durability and coalescing-sync settings. - - - Effect of different durability guarantees - - - - - Durability - Coalescing-sync - Description - - - - - 1 - NO_SYNC, NO_SYNC, SIMPLE_MAJORITY - true - Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of - coalescing-sync) and a majority of the replica(s) will have acknowledged the receipt - of the transaction. The replicas will write and sync the transaction to their disk at a point in the future governed by - ReplicationMutableConfig#LOG_FLUSH_INTERVAL. - - - - 2 - NO_SYNC, WRITE_NO_SYNC, SIMPLE_MAJORITY - true - Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of - coalescing-sync and a majority of the replica(s) will have acknowledged the write of - the transaction to their disk. The replicas will sync the transaction to disk at a point in the future with an upper bound governed by - ReplicationMutableConfig#LOG_FLUSH_INTERVAL. - - - 3 - NO_SYNC, NO_SYNC, NONE - false - After the commit returns to the client, the transaction is neither guaranteed to be written to the disk of the master - nor received by any of the replicas. The master and replicas will write and sync the transaction to their disk at a point - in the future with an upper bound governed by ReplicationMutableConfig#LOG_FLUSH_INTERVAL. This offers the weakest durability guarantee. - - - -
- -
-
- -
- Client failover configuration - The details about format of Qpid connection URLs can be found at section - Connection URLs - of book Programming In Apache Qpid. - The failover policy option in the connection URL for the HA Cluster should be set to roundrobin. - The Master broker should be put into a first place in brokerlist URL option. - The recommended value for connectdelay option in broker URL should be set to - the value greater than 1000 milliseconds. If it is desired that clients re-connect automatically after a - master to replica failure, cyclecount should be tuned so that the retry period is longer than - the expected length of time to perform the failover. - Example of connection URL for the HA Cluster -
- - -
- Qpid JMX API for HA - Qpid exposes the BDB HA store information via its JMX interface and provides APIs to remove a Node from - the group, update a Node IP address, and assign a Node as the designated primary. - An instance of the BDBHAMessageStore MBean is instantiated by the broker for the each virtualhost using the HA store. - The reference to this MBean can be obtained via JMX API using an ObjectName like org.apache.qpid:type=BDBHAMessageStore,name=<virtualhost name> - where <virtualhost name> is the name of a specific virtualhost on the broker. - - Mbean <classname>BDBHAMessageStore</classname> attributes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameTypeAccessibilityDescription
GroupNameStringRead onlyName identifying the group
NodeNameStringRead onlyUnique name identifying the node within the group
NodeHostPortStringRead onlyHost/port used to replicate data between this node and others in the group
HelperHostPortStringRead onlyHost/port used to allow a new node to discover other group members
NodeStateStringRead onlyCurrent state of the node
ReplicationPolicyStringRead onlyNode replication durability
DesignatedPrimarybooleanRead/WriteDesignated primary flag. Applicable to the two node case.
CoalescingSyncbooleanRead onlyCoalescing sync flag. Applicable to the master sync policies NO_SYNC and WRITE_NO_SYNC only.
getAllNodesInGroupTabularDataRead onlyGet all nodes within the group, regardless of whether currently attached or not
- - - Mbean <classname>BDBHAMessageStore</classname> operations - - - - - - - - - - - - - - - - - - - - - - -
OperationParametersReturnsDescription
removeNodeFromGroup - nodeName, name of node, string - voidRemove an existing node from the group
updateAddress - - - nodeName, name of node, string - - - newHostName, new host name, string - - - newPort, new port number, int - - - voidUpdate the address of another node. The node must be in a STOPPED state.
-
- BDBHAMessageStore view from jconsole. - -
- - Example of java code to get the node state value - environment = new HashMap(); - -// credentials: user name and password -environment.put(JMXConnector.CREDENTIALS, new String[] {"admin","admin"}); -JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9001/jmxrmi"); -JMXConnector jmxConnector = JMXConnectorFactory.connect(url, environment); -MBeanServerConnection mbsc = jmxConnector.getMBeanServerConnection(); - -ObjectName queueObjectName = new ObjectName("org.apache.qpid:type=BDBHAMessageStore,name=test"); -String state = (String)mbsc.getAttribute(queueObjectName, "NodeState"); - -System.out.println("Node state:" + state); - ]]> - Example system output: - - -
- -
- Monitoring cluster - In order to discover potential issues with HA Cluster early, all nodes in the Cluster should be monitored on regular basis - using the following techniques: - - - Broker log files scrapping for WARN or ERROR entries and operational log entries like: - - - MST-1007 : Store Passivated. It can indicate that Master virtual host has gone down. - - - MST-1006 : Recovery Complete. It can indicate that a former Replica virtual host is up and became the Master. - - - - - Disk space usage and system load using system tools. - - - Berkeley HA node status using DbPing utility. - Using <classname>DbPing</classname> utility for monitoring HA nodes. -java -jar je-&oracleBdbProductVersion;.jar DbPing -groupName TestClusterGroup -nodeName Node-5001 -nodeHost localhost:5001 -socketTimeout 10000 - -Current state of node: Node-5001 from group: TestClusterGroup - Current state: MASTER - Current master: Node-5001 - Current JE version: &oracleBdbProductVersion; - Current log version: 8 - Current transaction end (abort or commit) VLSN: 165 - Current master transaction end (abort or commit) VLSN: 0 - Current active feeders on node: 0 - Current system load average: 0.35 - - In the example above DbPing utility requested status of Cluster node with name - Node-5001 from replication group TestClusterGroup running on host localhost:5001. - The state of the node was reported into a system output. - - - - Using Qpid broker JMX interfaces. - Mbean BDBHAMessageStore can be used to request the following node information: - - - NodeState indicates whether node is a Master or Replica. - - - Durability replication durability. - - - DesignatedPrimary indicates whether Master node is designated primary. - - - GroupName replication group name. - - - NodeName node name. - - - NodeHostPort node host and port. - - - HelperHostPort helper host and port. - - - AllNodesInGroup lists of all nodes in the replication group including their names, hosts and ports. - - - For more details about BDBHAMessageStore MBean please refer section Qpid JMX API for HA - - -
- -
- Disk space requirements - Disk space is a critical resource for the HA Qpid broker. - In case when a Replica goes down (or falls behind the Master in 2 node cluster where the Master is designated primary) - and the Master continues running, the non-replicated store files are kept on the Masters disk for the period of time - as specified in je.rep.repStreamTimeout JE setting in order to replicate this data later - when the Replica is back. This setting is set to 1 hour by default by the broker. The setting can be overridden as described in - . - Depending from the application publishing/consuming rates and message sizes, - the disk space might become overfull during this period of time due to preserved logs. - Please, make sure to allocate enough space on your disk to avoid this from happening. - -
- -
- Network Requirements - The HA Cluster performance depends on the network bandwidth, its use by existing traffic, and quality of service. - In order to achieve the best performance it is recommended to use a separate network infrastructure for the Qpid HA Nodes - which might include installation of dedicated network hardware on Broker hosts, assigning a higher priority to replication ports, - installing a cluster in a separate network not impacted by any other traffic. -
- -
- Security - At the moment Berkeley replication API supports only TCP/IP protocol to transfer replication data between Master and Replicas. - As result, the replicated data is unprotected and can be intercepted by anyone having access to the replication network. - Also, anyone who can access to this network can introduce a new node and therefore receive a copy of the data. - In order to reduce the security risks the entire HA cluster is recommended to run in a separate network protected from general access. -
- -
- Backups - In order to protect the entire cluster from some cataclysms which might destroy all cluster nodes, - backups of the Master store should be taken on a regular basis. - Qpid Broker distribution includes the "hot" backup utility backup.sh which can be found at broker bin folder. - This utility can perform the backup when broker is running. - backup.sh script invokes org.apache.qpid.server.store.berkeleydb.BDBBackup to do the job. - You can also run this class from command line like in an example below: - Performing store backup by using <classname>BDBBackup</classname> class directly - java -cp qpid-bdbstore-0.18.jar org.apache.qpid.server.store.berkeleydb.BDBBackup -fromdir path/to/store/folder -todir path/to/backup/foldeAr - - In the example above BDBBackup utility is called from qpid-bdbstore-0.18.jar to backup the store at path/to/store/folder and copy store logs into path/to/backup/folder. - Linux and Unix users can take advantage of backup.sh bash script by running this script in a similar way. - Performing store backup by using <classname>backup.sh</classname> bash script - backup.sh -fromdir path/to/store/folder -todir path/to/backup/folder - - - Do not forget to ensure that the Master store is being backed up, in the event the Node elected Master changes during - the lifecycle of the cluster. - -
- -
- Migration of a non-HA store to HA - Non HA stores starting from schema version 4 (0.14 Qpid release) can be automatically converted into HA store on broker startup if replication is first enabled with the DbEnableReplication utility from the BDB JE jar. - DbEnableReplication converts a non HA store into an HA store and can be used as follows: - Enabling replication -java -jar je-&oracleBdbProductVersion;.jar DbEnableReplication -h /path/to/store -groupName MyReplicationGroup -nodeName MyNode1 -nodeHostPort localhost:5001 - - In the examples above, je jar of version &oracleBdbProductVersion; is used to convert store at /path/to/store into HA store having replication group name MyReplicationGroup, node name MyNode1 and running on host localhost and port 5001. - After running DbEnableReplication and updating the virtual host store to configuration to be an HA message store, like in example below, - on broker start up the store schema will be upgraded to the most recent version and the broker can be used as normal. - - Example of XML configuration for HA message store - - org.apache.qpid.server.store.berkeleydb.BDBHAMessageStore - /path/to/store - - MyReplicationGroup - MyNode1 - localhost:5001 - localhost:5001 - -]]> - - The Replica nodes can be started with empty stores. The data will be automatically copied from Master to Replica on Replica start-up. - This will take a period of time determined by the size of the Masters store and the network bandwidth between the nodes. - - Due to existing caveats in Berkeley JE with copying of data from Master into Replica it is recommended to restart the Master node after store schema upgrade is finished before starting the Replica nodes. - -
- -
- Disaster Recovery - This section describes the steps required to restore HA broker cluster from backup. - The detailed instructions how to perform backup on replicated environment can be found here. - At this point we assume that backups are collected on regular basis from Master node. - Replication configuration of a cluster is stored internally in HA message store. - This information includes IP addresses of the nodes. - In case when HA message store needs to be restored on a different host with a different IP address - the cluster replication configuration should be reseted in this case - Oracle provides a command line utility DbResetRepGroup - to reset the members of a replication group and replace the group with a new group consisting of a single new member - as described by the arguments supplied to the utility - Cluster can be restored with the following steps: - - Copy log files into the store folder from backup - - Use DbResetRepGroup to reset an existing environment. See an example below - - Reseting of replication group with <classname>DbResetRepGroup</classname> -java -cp je-&oracleBdbProductVersion;.jar com.sleepycat.je.rep.util.DbResetRepGroup -h ha-work/Node-5001/bdbstore -groupName TestClusterGroup -nodeName Node-5001 -nodeHostPort localhost:5001 - - In the example above DbResetRepGroup utility from Berkeley JE of version &oracleBdbProductVersion; is used to reset the store - at location ha-work/Node-5001/bdbstore and set a replication group to TestClusterGroup - having a node Node-5001 which runs at localhost:5001. - - Start a broker with HA store configured as specified on running of DbResetRepGroup utility. - Start replica nodes having the same replication group and a helper host port pointing to a new master. The store content will be copied into Replicas from Master on their start up. - -
- -
- Performance - The aim of this section is not to provide exact performance metrics relating to HA, as this depends heavily on the test - environment, but rather showing an impact of HA on Qpid broker performance in comparison with the Non HA case. - For testing of impact of HA on a broker performance a special test script was written using Qpid performance test framework. - The script opened a number of connections to the Qpid broker, created producers and consumers on separate connections, - and published test messages with concurrent producers into a test queue and consumed them with concurrent consumers. - The table below shows the number of producers/consumers used in the tests. - The overall throughput was collected for each configuration. - - - Number of producers/consumers in performance tests - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TestNumber of producersNumber of consumers
111
222
344
488
51616
63232
76464
- The test was run against the following Qpid Broker configurations - - - Non HA Broker - - - HA 2 Nodes Cluster with durability SYNC,SYNC,ALL - - - HA 2 Nodes Cluster with durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL - - - HA 2 Nodes Cluster with durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL and coalescing-sync Qpid mode - - - HA 2 Nodes Cluster with durability WRITE_NO_SYNC,NO_SYNC,ALL and coalescing-sync Qpid mode - - - HA 2 Nodes Cluster with durability NO_SYNC,NO_SYNC,ALL and coalescing-sync Qpid option - - - The evironment used in testing consisted of 2 servers with 4 CPU cores (2x Intel(r) Xeon(R) CPU 5150@2.66GHz), 4GB of RAM - and running under OS Red Hat Enterprise Linux AS release 4 (Nahant Update 4). Network bandwidth was 1Gbit. - - We ran Master node on the first server and Replica and clients(both consumers and producers) on the second server. - In non-HA case Qpid Broker was run on a first server and clients were run on a second server. - The table below contains the test results we measured on this environment for different Broker configurations. - Each result is represented by throughput value in KB/second and difference in % between HA configuration and non HA case for the same number of clients. - - Performance Comparison - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Test/BrokerNo HASYNC, SYNC, ALLWRITE_NO_SYNC, WRITE_NO_SYNC, ALLWRITE_NO_SYNC, WRITE_NO_SYNC, ALL - coalescing-syncWRITE_NO_SYNC, NO_SYNC,ALL - coalescing-syncNO_SYNC, NO_SYNC, ALL - coalescing-sync
1 (1/1)0.0%-61.4%117.0%-16.02%-9.58%-25.47%
2 (2/2)0.0%-75.43%67.87%-66.6%-69.02%-30.43%
3 (4/4)0.0%-84.89%24.19%-71.02%-69.37%-43.67%
4 (8/8)0.0%-91.17%-22.97%-82.32%-83.42%-55.5%
5 (16/16)0.0%-91.16%-21.42%-86.6%-86.37%-46.99%
6 (32/32)0.0%-94.83%-51.51%-92.15%-92.02%-57.59%
7 (64/64)0.0%-94.2%-41.84%-89.55%-89.55%-50.54%
- The figure below depicts the graphs for the performance test results -
- Test results - -
- On using durability SYNC,SYNC,ALL (without coalescing-sync) the performance drops significantly (by 62-95%) in comparison with non HA broker. - Whilst, on using durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL (without coalescing-sync) the performance drops by only half, but with loss of durability guarantee, so is not recommended. - In order to have better performance with HA, Qpid Broker comes up with the special mode called coalescing-sync, - With this mode enabled, Qpid broker batches the concurrent transaction commits and syncs transaction data into Master disk in one go. - As result, the HA performance only drops by 25-60% for durability NO_SYNC,NO_SYNC,ALL and by 10-90% for WRITE_NO_SYNC,WRITE_NO_SYNC,ALL. -
- -
diff --git a/doc/book/src/java-broker/How-to-Tune-M3-Java-Broker-Performance.xml b/doc/book/src/java-broker/How-to-Tune-M3-Java-Broker-Performance.xml deleted file mode 100644 index f7fffbaceb..0000000000 --- a/doc/book/src/java-broker/How-to-Tune-M3-Java-Broker-Performance.xml +++ /dev/null @@ -1,172 +0,0 @@ - - - -
- - How to Tune M3 Java Broker Performance - -
- - Problem - Statement - - - During destructive testing of the Qpid M3 Java Broker, we tested - some tuning techniques and deployment changes to improve the Qpid - M3 Java Broker's capacity to maintain high levels of throughput, - particularly in the case of a slower consumer than produceer - (i.e. a growing backlog). - - - The focus of this page is to detail the results of tuning & - deployment changes trialled. - - - The successful tuning changes are applicable for any deployment - expecting to see bursts of high volume throughput (1000s of - persistent messages in large batches). Any user wishing to use - these options must test them thoroughly in their own - environment with representative volumes. - - -
- -
- - Successful - Tuning Options - - - The key scenario being taregetted by these changes is a broker - under heavy load (processing a large batch of persistent - messages)can be seen to perform slowly when filling up with an - influx of high volume transient messages which are queued behind - the persistent backlog. However, the changes suggested will be - equally applicable to general heavy load scenarios. - - - The easiest way to address this is to separate streams of - messages. Thus allowing the separate streams of messages to be - processed, and preventing a backlog behind a particular slow - consumer. - - - These strategies have been successfully tested to mitigate this - problem: - - - - <tgroup cols="2"> - <tbody> - <row> - <entry> - Strategy - </entry> - <entry> - Result - </entry> - </row> - <row> - <entry> - Seperate connections to one broker for separate streams of - messages. - </entry> - <entry> - Messages processed successfully, no problems experienced - </entry> - </row> - <row> - <entry> - Seperate brokers for transient and persistent messages. - </entry> - <entry> - Messages processed successfully, no problems experienced - </entry> - </row> - </tbody> - </tgroup> - </table> - <para> - <emphasis>Separate Connections</emphasis> - Using separate connections effectively means that the two streams - of data are not being processed via the same buffer, and thus the - broker gets & processes the transient messages while - processing the persistent messages. Thus any build up of - unprocessed data is minimal and transitory. - </para> - <para> - <emphasis>Separate Brokers</emphasis> - Using separate brokers may mean more work in terms of client - connection details being changed, and from an operational - perspective. However, it is certainly the most clear cut way of - isolating the two streams of messages and the heaps impacted. - </para> - <section role="h4" id="HowtoTuneM3JavaBrokerPerformance-Additionaltuning"> - <title> - Additional - tuning - - - It is worth testing if changing the size of the Qpid read/write - thread pool improves performance (eg. by setting - JAVA_OPTS="-Damqj.read_write_pool_size=32" before running - qpid-server). By default this is equal to the number of CPU - cores, but a higher number may show better performance with some - work loads. - - - It is also important to note that you should give the Qpid broker - plenty of memory - for any serious application at least a -Xmx of - 3Gb. If you are deploying on a 64 bit platform, a larger heap is - definitely worth testing with. We will be testing tuning options - around a larger heap shortly. - - - - - - -
- - Next - Steps - - - These two options have been testing using a Qpid test case, and - demonstrated that for a test case with a profile of persistent - heavy load following by constant transient high load traffic they - provide significant improvment. - - - However, the deploying project must complete their own - testing, using the same destructive test cases, representative - message paradigms & volumes, in order to verify the proposed - mitigation options. - - - The using programme should then choose the option most applicable - for their deployment and perform BAU testing before any - implementation into a production or pilot environment. - - -
- diff --git a/doc/book/src/java-broker/How-to-Use-SlowConsumerDisconnect.xml b/doc/book/src/java-broker/How-to-Use-SlowConsumerDisconnect.xml deleted file mode 100644 index 4e0ce0f7e0..0000000000 --- a/doc/book/src/java-broker/How-to-Use-SlowConsumerDisconnect.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - -
- Slow Consumer Disconnect - User Guide - -
-Introduction - Slow Consumer Disconnect (SCD) is a new feature in Qpid that provides a configurable - mechanism to prevent a single slow consumer from causing a back up of unconsumed messages on - the broker. - - This is most relevant where Topics are in use, since a published message is not removed - from the broker's memory until all subscribers have acknowledged that message. - - Cases where a consumer is 'slow' can arise due to one of the following: poor network - connectivity exists; a transient system issue affects a single client; a single subscriber - written by a client team is behaving incorrectly and not acknowledging messages; a - downstream resource such as a database is non-responsive. - - SCD will enable the application owner to configure limits for a given consumer's queue and - the behaviour to execute when those limits are reached. - -
- -
-What can it do? - SCD is only applicable to topics or durable subscriptions and can be configured on either - a topic or a subscription name. - - On triggering of a specified threshold the offending client will be disconnected from the - broker with a 506 error code wrapped in a JMSException returned to the client via the - ExceptionListener registered on the Connection object. - - Note that it is essential that an ExceptionListener be specified by the client on - creation of the connection and that exceptions coming back on that listener are handled - correctly. - -
- -
-Frequency of SCD Checking -
-<emphasis role='bold'>Configuring Frequency</emphasis> - You can configure the frequency with which the SCD process will check for slow consumers, - along with the unit of time used to specify that frequency. - - The virtualhosts.virtualhost.hostname.slow-consumer-detection - elements delay and timeunit - are used to specify the frequency and timeunit respectively in the virtualhosts.xml - file e.g. - - -<virtualhosts> - <default>test</default> - <virtualhost> - <name>test</name> - <test> - <slow-consumer-detection> - <delay>60<delay/> - <timeunit>seconds<timeunit/> - <slow-consumer-detection/> - </test> - </virtualhost> -</virtualhosts> - - -
- -
-<emphasis role='bold'>SCD Log output</emphasis> - When the SCD component finds a queue with a configured threshold to check, the operational - logging component (if enabled) will output the following line: - - - SCD-1003 : Checking Status of Queue - - -
- -
- -
-Client Exception<emphasis role='bold'>s</emphasis> - When a Slow Consumer is disconnected, the client receives a 506 error from the broker - wrapped in a JMSException and the Session and Connection are closed: - - -Dispatcher-Channel-1 2010-09-01 16:23:34,206 INFO [qpid.client.AMQSession.Dispatcher] - Dispatcher-Channel-1 thread terminating for channel 1:org.apache.qpid.client.AMQSession_0_8@1de8aa8 -pool-2-thread-3 2010-09-01 16:23:34,238 INFO [apache.qpid.client.AMQConnection] Closing AMQConnection due to - :org.apache.qpid.AMQChannelClosedException: Error: Consuming to slow. [error code 506: resource error] -javax.jms.JMSException: 506 -at org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1396) -at org.apache.qpid.client.protocol.AMQProtocolHandler.exception(AMQProtocolHandler.java:329) -at org.apache.qpid.client.protocol.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:536) -at org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:453) -at org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:93) -at org.apache.qpid.client.protocol.AMQProtocolHandler$1.run(AMQProtocolHandler.java:462) -at org.apache.qpid.pool.Job.processAll(Job.java:110) -at org.apache.qpid.pool.Job.run(Job.java:149) -at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) -at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) -at java.lang.Thread.run(Thread.java:619) -Caused by: org.apache.qpid.AMQChannelClosedException: Error: Consuming to slow. [error code 506: resource error] -at org.apache.qpid.client.handler.ChannelCloseMethodHandler.methodReceived(ChannelCloseMethodHandler.java:96) -at org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchChannelClose(ClientMethodDispatcherImpl.java:163) -at org.apache.qpid.framing.amqp_8_0.ChannelCloseBodyImpl.execute(ChannelCloseBodyImpl.java:140) -at org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:112) -at org.apache.qpid.client.protocol.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:511) -... 8 more -main 2010-09-01 16:23:34,316 INFO [apache.qpid.client.AMQSession] Closing session: - org.apache.qpid.client.AMQSession_0_8@ffeef1 - - -
- -
-Disconnection Thresholds -
-Topic Subscriptions - One key feature of SCD is the disconnection of a consuming client when a specified - threshold is exceeded. For a pub-sub model using topics, this means that messages will no - longer be delivered to the private queue which was associated with that consuming client, - thus reducing any associated backlog in the broker. - -
- -
-Durable Topic Subscriptions - For durable subscriptions, simply disconnecting the consuming client will not suffice - since the associated queue is by definition durable and messages would continue to flow to - it after disconnection, potentially worsening any backing up of data on the broker. - - The solution is to configure durable subscriptions to delete the underlying queue on - disconnection. This means that messages will no longer be delivered to the private queue - associated with the subscription, thus preventing any backlog. - - Full details of how to configure the thresholds are provided below. - -
- -
-Message Age Threshold - You can configure SCD to be triggered on a topic or subscription when the oldest message - in the associated private queue for the consumer ages beyond the specified value, in - milliseconds. - -
- -
-Queue Depth Threshold - You can opt to use the depth of the queue in bytes as a threshold. SCD will be triggered - by a queue depth greater than the threshold specified i.e. when a broker receives a - message that takes the queue depth over the threshold. - -
- -
-Message Count Threshold - You can use the message count for the consumer's queue as the trigger, where a count - higher than that specified will trigger disconnection. - -
- -
-<emphasis role='bold'>Delete Policy</emphasis> - You can configure the policy you wish to apply in your broker configuration. There are - currently 2 policies available: - - -Delete Temporary Queues Only - - - If you do not specify a <topicDelete/> element in your configuration, then only temporary - queues associated with a topic subscription will be deleted on client disconnect. This is - the default behaviour. - - - -Delete Durable Subscription Queues - - - If you add the <topicDelete/> element with the sub-element - <delete-persistent/> to your config, then the persistent queue which is associated - with durable subscriptions to a topic will also be deleted. This is an important - consideration since without deleting the underlying queue the client's unconsumed data - will grow indefinitely while they will be unable to reconnect to that queue due to the SCD - threshold configured, potentially having an adverse effect on the application or broker in - use. - - - Example Topic Configuration - - - - -The following steps are required to configure SCD: - - - - - Enable SCD checking for your virtual host - - - Specify frequency for SCD checking - - - Define thresholds for the topic - - - Define the policy to apply on trigger - - - - The example below shows a simple definition, with all three thresholds specified and a - simple disconnection, with deletion of any temporary queue, defined. - - For a durable subscription to this topic, no queue deletion would be applied on disconnect - - which is likely to be undesirable (see section above). - - -<topics> - <topic> - <name>stocks.us.*</name> - <slow-consumer-detection> - <!-- The maximum depth before which --> - <!-- the policy will be applied--> - <depth>4235264</depth> - <!-- The maximum message age before which --> - <!-- the policy will be applied--> - <messageAge>600000</messageAge> - <!-- The maximum number of message before --> - <!-- which the policy will be applied--> - <messageCount>50</messageCount> - <!-- Policy Selection --> - <policy name="TopicDelete"/> - </slow-consumer-detection> - </topic> -</topics> - - -
- -
- -
-Important Points To Note - Client application developers should be educated about how to correctly handle being - disconnected with a 506 error code, to avoid them getting into a thrashing state where they - continually attempt to connect, fail to consume fast enough and are disconnected again. - - Clients affected by slow consumer disconnect configuration should always use transactions - where duplicate processing of an incoming message would have adverse affects, since they may - receive a message more than once if disconnected before acknowledging a message in flight. - -
- -
- diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Authentication-Providers.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Authentication-Providers.xml new file mode 100644 index 0000000000..3a2825826b --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Authentication-Providers.xml @@ -0,0 +1,26 @@ + + + +
+Authentication Providers + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Exchanges.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Exchanges.xml new file mode 100644 index 0000000000..af14b46a69 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Exchanges.xml @@ -0,0 +1,26 @@ + + + +
+Exchanges + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Other-Services.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Other-Services.xml new file mode 100644 index 0000000000..bb694d81da --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Other-Services.xml @@ -0,0 +1,26 @@ + + + +
+Other Services + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Ports.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Ports.xml new file mode 100644 index 0000000000..afbb612bc4 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Ports.xml @@ -0,0 +1,26 @@ + + + +
+Ports + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Protocols.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Protocols.xml new file mode 100644 index 0000000000..45a62ce5ab --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Protocols.xml @@ -0,0 +1,26 @@ + + + +
+Protocols + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Queues.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Queues.xml new file mode 100644 index 0000000000..a4b0995a7e --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Queues.xml @@ -0,0 +1,26 @@ + + + +
+Queues + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts-Virtual-Hosts.xml b/doc/book/src/java-broker/Java-Broker-Concepts-Virtual-Hosts.xml new file mode 100644 index 0000000000..c12a543140 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts-Virtual-Hosts.xml @@ -0,0 +1,26 @@ + + + +
+Virtual Hosts + +
diff --git a/doc/book/src/java-broker/Java-Broker-Concepts.xml b/doc/book/src/java-broker/Java-Broker-Concepts.xml new file mode 100644 index 0000000000..013308fb8f --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Concepts.xml @@ -0,0 +1,32 @@ + + + + + Concepts + + + + + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Config-Files.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Config-Files.xml new file mode 100644 index 0000000000..66d471fb37 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Config-Files.xml @@ -0,0 +1,178 @@ + + + +
+Config Files + + + This section shows how to configure and manage broker. + + +
+ Configuration file + Broker can be configured using XML configuration files. By default, broker is looking for configuration file at ${QPID_HOME}/etc/config.xml. The default configuration location can be overridden by specifying command line option -c <path to configuration> on broker start up. +
+ +
+ Management Configuration + + Management interfaces can be configured in management section of broker configuration file. The example of the management section is provided below. + + + Management configuration + + ... + + true + + 8999 + + + false + ${conf}/qpid.keystore + password + + + true + + + false + + + ... + ]]> + +
+
+ JMX Management Configuration + + JMX management can be configured in management section of broker configuration file. + + An enabled element in the management section is used to enable or disable the JMX interfaces. Setting it to true causes the broker to start the management plugin if such is available on the broker classpath. + JMX management requires two ports which can be configured in jmxport sub-section of management: + + RMI port (8999 by default) can be configured in an element jmxport/registryServer + Connector port can be configured in an element jmxport/connectorServer. If configuration element connectorServer is not provided than the connector port defaults to 100 + registryServer port. + + + + Enabling JMX Management and configuring JMX ports + +<broker> +... +<management> + <enabled>true</enabled> + <jmxport> + <registryServer>7999</registryServer> + <connectorServer>7998</connectorServer> + </jmxport> +</management> +... +</broker> + + In the snippet above the following is configured: + + Enable JMX management + Set RMI port to 7999 + Set connector port to 7998 + + SSL can be configured to use on the connector port in the sub-section ssl of the management section. See for details. + In order to use SSL with JMX management an element ssl/enabled needs to be set to true. +
+
+ Management SSL key store configuration + + This section describes how to configure the key store to use in SSL connections in both JMX and Web management interfaces. + + The following examples demonstrates how to configure keystore for management + + Management key store configuration + +<broker> +... +<management> +... + <ssl> + <enabled>true</enabled> + <keyStorePath>${conf}/qpid.keystore</keyStorePath> + <keyStorePassword>password</keyStorePassword> + </ssl> +... +</management> +... +</broker> + + + Enable SSL on JMX connector port only. This setting does not effect the web management interfaces. + Set path to the key store file + Set keystore password + +
+
+ Web Management Configuration + + Web management can be configured in management section of broker configuration file. + + Sub-section http is used to enable web management on http port. + Sub-section https is used to enable web management on https port. + The following example shows how to configure http and https ports + + Enabling web management + +<broker> +... +<management> +... + <http> + <enabled>true</enabled> + <port>9090</port> + <basic-auth>false</basic-auth> + <sasl-auth>true</sasl-auth> + <session-timeout>600</session-timeout> + </http> + + <https> + <enabled>true</enabled> + <port>9443</port> + <sasl-auth>true</sasl-auth> + <basic-auth>true</basic-auth> + </https> +... +</management> +... +</broker> + + + Enable web management on http port. Default is true. + Set web management http port to 9090. Default is 8080. + Disable basic authentication on http port for REST services only. Default is false. + Enable SASL authentication on http port for REST services and web console. Default is true. + Set session timeout in seconds. Default is 15 minutes. + Enable web management on https port. Default is false. + Set web management https port to 9443. Default is 8443. + Enable SASL authentication on https port for REST services and web console. Default is true. + Enable basic authentication on https port for REST services only. Default is true. + + Please configure the keystore to use with the https web management port. See for details. +
+
diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-JMX.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-JMX.xml new file mode 100644 index 0000000000..122da6d267 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-JMX.xml @@ -0,0 +1,26 @@ + + + +
+JMX + +
diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Other-Tooling.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Other-Tooling.xml new file mode 100644 index 0000000000..cf9d9497dd --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Other-Tooling.xml @@ -0,0 +1,26 @@ + + + +
+Other Tooling + +
diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-REST-API.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-REST-API.xml new file mode 100644 index 0000000000..8bd63ade7a --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-REST-API.xml @@ -0,0 +1,263 @@ + + + +
+REST API +
+ REST API Overview + This section provides an overview of REST management API. + If web management is enabled (see ) + the REST API can be used to monitor and manage the broker instance. + The Qpid broker REST services support traditional REST model which uses the GET method requests to retrieve + the information about broker configured objects, DELETE method requests to delete the configured object, + PUT to create the configured object and POST to update the configured objects. + The table below lists the available REST services with brief description how they can be used. + +
+ Rest services + + + + Rest service URL + Description + GET + PUT + POST + DELETE + + + + + /rest/broker + Rest service to manage broker instance + Retrieves the details of broker configuration + Not implemented yet + Not implemented yet + Not implemented yet + + + /rest/authenticationprovider + /rest/authenticationprovider/<authentication provider name> + + Rest service to manage authentication providers on the broker + Retrieves the details about authentication providers + Not implemented yet + Not implemented yet + Not implemented yet + + + /rest/user + /rest/user/<authentication provider name>/<user name> + + Rest service to manage user account + Retrieves the details about user account + Creates user account + Updates user password + Deletes user account + + + /rest/groupprovider + /rest/groupprovider/<group provider name> + + Rest service to manage group providers + Retrieves the details about group provider(s) + Not implemented yet + Not implemented yet + Not implemented yet + + + /rest/group + /rest/group/<group provider name>/<group name> + + Rest service to manage user group + Retrieves the details about user group + Creates group + Not implemented yet + Deletes group + + + /rest/groupmember + /rest/groupmember/<group provider name >/<group name>/<user name> + + Rest service to manage group member(s) + Retrieves the details about group member(s) + Add user to group + Not implemented yet + Deletes user from group + + + + /rest/port + /rest/port/<port name> + + Rest service to manage broker ports(s) + Retrieves the details about the broker port(s) + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/port + /rest/port/<port name> + + Rest service to manage broker ports(s) + Retrieves the details about the broker port(s) + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/queue + /rest/queue/<virtual host name>/>queue name> + + Rest service to manage queue(s) + Retrieves the details about the queue(s) + Creates queue + Not implemented yet + Deletes queue + + + + /rest/exchange + /rest/exchange/<virtual host name>/<exchange name> + + Rest service to manage exchange(s) + Retrieves the details about the exchange(s) + Creates exchange + Not implemented yet + Deletes exchange + + + + /rest/binding + /rest/binding/<virtual host name>/<exchange name>/<queue name>/<binding name> + + Rest service to manage binding(s) + Retrieves the details about the binding(s) + Binds a queue to an exchange + Not implemented yet + Deletes binding + + + + /rest/connection + /rest/connection/<virtual host name>/<connection name> + + Rest service to manage connection(s) + Retrieves the details about the connection(s) + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/session + /rest/session/<virtual host name>/<connection name>/<session name> + + Rest service to manage session(s) + Retrieves the details about the session(s) + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/message/* + + Rest service to manage messages(s) + Retrieves the details about the messages(s) + Not implemented yet + Copies, moves messages + Deletes messages + + + + /rest/message-content/* + + Rest service to retrieve message content + Retrieves the message content + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/logrecords + + Rest service to retrieve broker logs + Retrieves the broker logs + Not implemented yet + Not implemented yet + Not implemented yet + + + + /rest/sasl + + Sasl authentication + Retrieves user current authentication status and broker supported SASL mechanisms + Authenticates user using supported SASL mechanisms + Not implemented yet + Not implemented yet + + + + /rest/logout + + Log outs + Log outs user + Not implemented yet + Not implemented yet + Not implemented yet + + + +
+ Rest URL are hierarchical. It is permitted to replace rest URL elements with an "asterisks" in GET requests to denote + all object of a particular type. Additionally, trailing object type in the URL hierarchy can be omitted. + In this case GET request will return all of the object underneath of the current object. + For example, for binding URL http://localhost:8080/rest/binding/<vhost>/<exchange>/<queue>/<binding> + replacing of <exchange> with "asterisks" (http://localhost:8080/rest/binding/<vhost>/*/<queue>/<binding>) + will result in the GET response containing the list of bindings for all of the exchanges in the virtual host having the given name and given queue. + If <binding> and <queue> are omitted in binding REST URL + (http://localhost:8080/rest/binding/<vhostname>/<exchangename>) the GET request will result in returning + all bindings for all queues for the given exchange in the virtual host. + + + Examples of queue creation using curl: + / +#create a durable priority queue +curl -X PUT -d '{"durable":true,"type":"priority"}' http://localhost:8080/rest/queue// + ]]> + + Example of binding a queue to an exchange using curl + /// + ]]> + + Qpid broker web management console calls rest interfaces internally to manage the broker. +
+
diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Web-Console.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Web-Console.xml new file mode 100644 index 0000000000..406f2fbe08 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing-Web-Console.xml @@ -0,0 +1,35 @@ + + + +
+ Web Console + If web management is enabled (see ) the web management console can be accessed from web browser using URL http(s)://<hostname>:<port>/management, where + + hostname is the broker host + port is the broker port(either http or https) + + The page like following is displayed on navigation to the management URL. +
+ Web management Console + +
+
diff --git a/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing.xml b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing.xml new file mode 100644 index 0000000000..d0858a80c0 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Configuring-And-Managing.xml @@ -0,0 +1,30 @@ + + + + + Configuring And Managing + + + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Exchanges-Binding-Arguments.xml b/doc/book/src/java-broker/Java-Broker-Exchanges-Binding-Arguments.xml new file mode 100644 index 0000000000..06c5ee7336 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Exchanges-Binding-Arguments.xml @@ -0,0 +1,26 @@ + + + +
+ + +
diff --git a/doc/book/src/java-broker/Java-Broker-Exchanges.xml b/doc/book/src/java-broker/Java-Broker-Exchanges.xml new file mode 100644 index 0000000000..f6272fb0f3 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Exchanges.xml @@ -0,0 +1,26 @@ + + + + + Exchanges + + diff --git a/doc/book/src/java-broker/Java-Broker-Feature-Guide.xml b/doc/book/src/java-broker/Java-Broker-Feature-Guide.xml deleted file mode 100644 index bbc2a1aaf0..0000000000 --- a/doc/book/src/java-broker/Java-Broker-Feature-Guide.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - -
- - Java Broker Feature Guide - -
- - The Qpid pure Java broker currently supports the following - features: - - - All features required by the Sun JMS 1.1 specification, fully - tested - - Transaction support - - Persistence using a pluggable layer - - Pluggable security using SASL - - Management using JMX and an Eclipse Management Console - application - - High performance header-based routing for messages - - Message Priorities - - Configurable logging and log archiving - - Threshold alerting - - ACLs - - Extensively tested on each release, including performance - & reliability testing - - Automatic client failover using configurable connection - properties - - Durable Queues/Subscriptions - - -
- - Upcoming - features: - - - Flow To Disk - - IP Whitelist - - AMQP 0-10 Support (for interoperability) - - - - -
- - -
- -
diff --git a/doc/book/src/java-broker/Java-Broker-Getting-Started.xml b/doc/book/src/java-broker/Java-Broker-Getting-Started.xml new file mode 100644 index 0000000000..630c27ce89 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Getting-Started.xml @@ -0,0 +1,140 @@ + + +%entities; +]> + + + + Getting Started + This section describes how to start the Java Broker for the first time. +
+ Starting/Stopping the Broker + To start the Broker, use the qpid-server script (UNIX) or qpid-server.bat (Windows) + provided within distribution. +
+
+ Starting/Stopping on Windows + Firstly change to the installation directory used during the installation + and ensure that the QPID_WORK environment variable is set. + Now use the qpid-server.bat to start the server + + Output similar to the following will be seen: + [Broker] BRK-1006 : Using configuration : C:\qpid\qpid-broker-&qpidCurrentRelease;\etc\config.xml +[Broker] BRK-1007 : Using logging configuration : C:\qpid\qpid-broker-&qpidCurrentRelease;\etc\log4j.xml +[Broker] BRK-1001 : Startup : Version: &qpidCurrentRelease; Build: 1411386 +[Broker] BRK-1010 : Platform : JVM : Sun Microsystems Inc. version: 1.6.0_24-b07 OS : Windows 7 version: 6.1 arch: amd64 +[Broker] BRK-1011 : Maximum Memory : 1,069,416,448 bytes +[Broker] MNG-1001 : Web Management Startup +[Broker] MNG-1002 : Starting : HTTP : Listening on port 8080 +[Broker] MNG-1004 : Web Management Ready +[Broker] MNG-1001 : JMX Management Startup +[Broker] MNG-1002 : Starting : RMI Registry : Listening on port 8999 +[Broker] MNG-1002 : Starting : JMX RMIConnectorServer : Listening on port 9099 +[Broker] MNG-1004 : JMX Management Ready +[Broker] BRK-1002 : Starting : Listening on TCP port 5672 +[Broker] BRK-1004 : Qpid Broker Ready + The BRK-1004 message confirms that the Broker is ready for work. The MNG-1002 and BRK-1002 confirm the ports to + which the Broker is listening (for HTTP/JMX management and AMQP respectively). + To stop the Broker, use Control-C or use the Shutdown MBean made from the +
+
+ Starting/Stopping on Unix + Firstly change to the installation directory used during the installation + and ensure that the QPID_WORK environment variable is set. + Now use the qpid-server script to start the server: + + Output similar to the following will be seen: + [Broker] BRK-1006 : Using configuration : /usr/local/qpid/qpid-broker-&qpidCurrentRelease;/etc/config.xml +[Broker] BRK-1007 : Using logging configuration : /usr/local/qpid/qpid-broker-&qpidCurrentRelease;/etc/log4j.xml +[Broker] BRK-1001 : Startup : Version: &qpidCurrentRelease; Build: 1411386 +[Broker] BRK-1010 : Platform : JVM : Apple Inc. version: 1.6.0_35-b10-428-11M3811 OS : Mac OS X version: 10.8.2 arch: x86_64 +[Broker] BRK-1011 : Maximum Memory : 1,070,399,488 bytes +[Broker] MNG-1001 : Web Management Startup +[Broker] MNG-1002 : Starting : HTTP : Listening on port 8080 +[Broker] MNG-1004 : Web Management Ready +[Broker] MNG-1001 : JMX Management Startup +[Broker] MNG-1002 : Starting : RMI Registry : Listening on port 8999 +[Broker] MNG-1002 : Starting : JMX RMIConnectorServer : Listening on port 9099 +[Broker] MNG-1004 : JMX Management Ready +[Broker] BRK-1002 : Starting : Listening on TCP port 5672 +[Broker] BRK-1004 : Qpid Broker Ready + The BRK-1004 message confirms that the Broker is ready for work. The MNG-1002 and BRK-1002 confirm the ports to + which the Broker is listening (for HTTP/JMX management and AMQP respectively). + To stop the Broker, use Control-C from the controlling shell, use the + bin/qpid.stop script, or use kill -TERM <pid> or + the Shutdown MBean from +
+
+ Log file + The Java Broker writes a log file to record both details of its normal operation and any exceptional + conditions. By default the log file is written within the log subdirectory beneath the work directory + - $QPID_WORK/log/qpid.log (UNIX) and + %QPID_WORK%\log\qpid.log (Windows). + For details of how to control the logging, see +
+
+ Using the command line + The Java Broker understands a number of command line options which may be used to override the configuration. + To see usage information for all command line options, use the option + + ] [-c ] [--exclude-0-10 ] [--exclude-0-8 ] [--exclude-0-9 ] [--exclude-0-9-1 + ] [--exclude-1-0 ] [-h] [--include-0-10 ] [--include-0-8 ] [--include-0-9 ] [--include-0-9-1 + ] [--include-1-0 ] [--jmxconnectorport ] [-l ] [-m ] [-p ] [-s ] [-v] [-w ] + -b,--bind
bind to the specified address. Overrides any value in the config file + -c,--config use given configuration file + --exclude-0-10 when listening on the specified port do not accept AMQP0-10 connections. The + specified port must be one specified on the command line + --exclude-0-8 when listening on the specified port do not accept AMQP0-8 connections. The + specified port must be one specified on the command line + --exclude-0-9 when listening on the specified port do not accept AMQP0-9 connections. The + specified port must be one specified on the command line + --exclude-0-9-1 when listening on the specified port do not accept AMQP0-9-1 connections. The + specified port must be one specified on the command line + --exclude-1-0 when listening on the specified port do not accept AMQP1-0 connections. The + specified port must be one specified on the command line + -h,--help print this message + --include-0-10 accept AMQP0-10 connections on this port, overriding configuration to the contrary. + The specified port must be one specified on the command line + --include-0-8 accept AMQP0-8 connections on this port, overriding configuration to the contrary. + The specified port must be one specified on the command line + --include-0-9 accept AMQP0-9 connections on this port, overriding configuration to the contrary. + The specified port must be one specified on the command line + --include-0-9-1 accept AMQP0-9-1 connections on this port, overriding configuration to the contrary. + The specified port must be one specified on the command line + --include-1-0 accept AMQP1-0 connections on this port, overriding configuration to the contrary. + The specified port must be one specified on the command line + --jmxconnectorport listen on the specified management (connector server) port. Overrides any + value in the config file + -l,--logconfig use the specified log4j xml configuration file. By default looks for a file named + etc/log4j.xml in the same directory as the configuration file + -m,--jmxregistryport listen on the specified management (registry server) port. Overrides any + value in the config file + -p,--port listen on the specified port. Overrides any value in the config file + -s,--sslport SSL port. Overrides any value in the config file + -v,--version print the version information and exit + -w,--logwatch monitor the log file configuration file for changes. Units are seconds. Zero means + do not check for changes.]]> +
+ + diff --git a/doc/book/src/java-broker/Java-Broker-High-Availability.xml b/doc/book/src/java-broker/Java-Broker-High-Availability.xml new file mode 100644 index 0000000000..7ea9dae38a --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-High-Availability.xml @@ -0,0 +1,1005 @@ + + +%entities; +]> + + + High Availability + +
+ General Introduction + The term High Availability (HA) usually refers to having a number of instances of a service such as a Message Broker + available so that should a service unexpectedly fail, or requires to be shutdown for maintenance, users may quickly connect + to another instance and continue their work with minimal interuption. HA is one way to make a overall system more resilient + by eliminating a single point of failure from a system. + HA offerings are usually categorised as Active/Active or Active/Passive. + An Active/Active system is one where all nodes within the cluster are usuaully available for use by clients all of the time. In an + Active/Passive system, one only node within the cluster is available for use by clients at any one time, whilst the others are in + some kind of standby state, awaiting to quickly step-in in the event the active node becomes unavailable. + +
+ +
+ HA offerings of the Java Broker + The Java Broker's HA offering became available at release 0.18. HA is provided by way of the HA + features built into the Java Edition of the Berkley Database (BDB JE) and as such + is currently only available to Java Broker users who use the optional BDB JE based persistence store. This + optional store requires the use of BDB JE which is licensed under the Sleepycat Licence, which is + not compatible with the Apache Licence and thus BDB JE is not distributed with Qpid. Users who elect to use this optional store for + the broker have to provide this dependency. + HA in the Java Broker provides an Active/Passive mode of operation with Virtual hosts being + the unit of replication. The Active node (referred to as the Master) accepts all work from all the clients. + The Passive nodes (referred to as Replicas) are unavailable for work: the only task they must perform is + to remain in synch with the Master node by consuming a replication stream containing all data and state. + If the Master node fails, a Replica node is elected to become the new Master node. All clients automatically failover + The automatic failover feature is available only for AMQP connections from the Java client. Management connections (JMX) + do not current offer this feature. to the new Master and continue their work. + The Java Broker HA solution is incompatible with the HA solution offered by the CPP Broker. It is not possible to co-locate Java and CPP + Brokers within the same cluster. + HA is not currently available for those using the the Derby Store or Memory + Message Store. +
+ +
+ Two Node Cluster +
+ Overview + In this HA solution, a cluster is formed with two nodes. one node serves as + master and the other is a replica. + + All data and state required for the operation of the virtual host is automatically sent from the + master to the replica. This is called the replication stream. The master virtual host confirms each + message is on the replica before the client transaction completes. The exact way the client awaits + for the master and replica is gorverned by the durability + configuration, which is discussed later. In this way, the replica remains ready to take over the + role of the master if the master becomes unavailable. + + It is important to note that there is an inherent limitation of two node clusters is that + the replica node cannot make itself master automatically in the event of master failure. This + is because the replica has no way to distinguish between a network partition (with potentially + the master still alive on the other side of the partition) and the case of genuine master failure. + (If the replica were to elect itself as master, the cluster would run the risk of a + split-brain scenario). + In the event of a master failure, a third party must designate the replica as primary. This process + is described in more detail later. + + Clients connect to the cluster using a failover url. + This allows the client to maintain a connection to the master in a way that is transparent + to the client application. +
+
+ Depictions of cluster operation + In this section, the operation of the cluster is depicted through a series of figures + supported by explanatory text. +
+ Key for figures + + + + + + Key to figures + + +
+
+ Normal Operation + The figure below illustrates normal operation. Clients connecting to the cluster by way + of the failover URL achieve a connection to the master. As clients perform work (message + production, consumption, queue creation etc), the master additionally sends this data to the + replica over the network. +
+ Normal operation of a two-node cluster + + + + + + Normal operation + + +
+
+
+ Master Failure and Recovery + The figure below illustrates a sequence of events whereby the master suffers a failure + and the replica is made the master to allow the clients to continue to work. Later the + old master is repaired and comes back on-line in replica role. + The item numbers in this list apply to the numbered boxes in the figure below. + + + System operating normally + + + Master suffers a failure and disconnects all clients. Replica realises that it is no + longer in contact with master. Clients begin to try to reconnect to the cluster, although these + connection attempts will fail at this point. + + + A third-party (an operator, a script or a combination of the two) verifies that the master has truely + failed and is no longer running. If it has truely failed, the decision is made + to designate the replica as primary, allowing it to assume the role of master despite the other node being down. + This primary designation is performed using JMX. + + + Client connections to the new master succeed and the service is restored + , albeit without a replica. + + + The old master is repaired and brought back on-line. It automatically rejoins the cluster + in the replica role. + + +
+ Failure of master and recovery sequence + + + + + + Failure of master and subsequent recovery sequence + + +
+
+
+ Replica Failure and Recovery + The figure that follows illustrates a sequence of events whereby the replica suffers a failure + leaving the master to continue processing alone. Later the replica is repaired and is restarted. + It rejoins the cluster so that it is once again ready to take over in the event of master failure. + The behavior of the replica failure case is governed by the designatedPrimary + configuration item. If set true on the master, the master will continue to operate solo without outside + intervention when the replica fails. If false, a third-party must designate the master as primary in order + for it to continue solo. + The item numbers in this list apply to the numbered boxes in the figure below. This example assumes + that designatedPrimary is true on the original master node. + + + System operating normally + + + Replica suffers a failure. Master realises that replica longer in contact but as + designatedPrimary is true, master continues processing solo and thus client + connections are uninterrupted by the loss of the replica. System continues operating normally, albeit + with a single node. + + + Replica is repaired. + + + After catching up with missed work, replica is once again ready to take over in the event of master failure. + + +
+ Failure of replica and subsequent recovery sequence + + + + + + Failure of replica and subsequent recovery sequence + + +
+
+
+ Network Partition and Recovery + The figure below illustrates the sequence of events that would occur if the network between + master and replica were to suffer a partition, and the nodes were out of contact with one and other. + As with Replica Failure and Recovery, the + behaviour is governed by the designatedPrimary. + Only if designatedPrimary is true on the master, will the master continue solo. + The item numbers in this list apply to the numbered boxes in the figure below. This example assumes + that designatedPrimary is true on the original master node. + + + System operating normally + + + Network suffers a failure. Master realises that replica longer in contact but as + designatedPrimary is true, master continues processing solo and thus client + connections are uninterrupted by the network partition between master and replica. + + + Network is repaired. + + + After catching up with missed work, replica is once again ready to take over in the event of master failure. + System operating normally again. + + +
+ Partition of the network separating master and replica + + + + + + Network Partition and Recovery + + +
+
+
+ Split Brain + A split-brain + is a situation where the two node cluster has two masters. BDB normally strives to prevent + this situation arising by preventing two nodes in a cluster being master at the same time. + However, if the network suffers a partition, and the third-party intervenes incorrectly + and makes the replica a second master a split-brain will be formed and both masters will + proceed to perform work independently of one and other. + There is no automatic recovery from a split-brain. + Manual intervention will be required to choose which store will be retained as master + and which will be discarded. Manual intervention will be required to identify and repeat the + lost business transactions. + The item numbers in this list apply to the numbered boxes in the figure below. + + + System operating normally + + + Network suffers a failure. Master realises that replica longer in contact but as + designatedPrimary is true, master continues processing solo. Client + connections are uninterrupted by the network partition. + A third-party erroneously designates the replica as primary while the + original master continues running (now solo). + + + As the nodes cannot see one and other, both behave as masters. Clients may perform work against + both master nodes. + + +
+ Split Brain + + + + + + Split Brain + + +
+
+
+
+ +
+ Multi Node Cluster + Multi node clusters, that is clusters where the number of nodes is three or more, are not yet + ready for use. +
+ +
+ Configuring a Virtual Host to be a node + To configure a virtualhost as a cluster node, configure the virtualhost.xml in the following manner: + + + + Configuring a VirtualHost to use the BDBHAMessageStore + + myhost + + + org.apache.qpid.server.store.berkeleydb.BDBHAMessageStore + ${work}/bdbhastore + + myclustername + mynode1 + node1host:port + node1host:port + NO_SYNC\,NO_SYNC\,SIMPLE_MAJORITY + true|false + true|false + + + ... + +]]> + + + The groupName is the name of logical name of the cluster. All nodes within the + cluster must use the same groupName in order to be considered part of the cluster. + The nodeName is the logical name of the node. All nodes within the cluster must have a + unique name. It is recommended that the node name should be chosen from a different nomenclature from that of + the servers on which they are hosted, in case the need arises to move node to a new server in the future. + The nodeHostPort is the hostname and port number used by this node to communicate with the + the other nodes in the cluster. For the hostname, an IP address, hostname or fully qualified hostname may be used. + For the port number, any free port can be used. It is important that this address is stable over time, as BDB + records and uses this address internally. + The helperHostPort is the hostname and port number that new nodes use to discover other + nodes within the cluster when they are newly introduced to the cluster. When configuring the first node, set the + helperHostPort to its own nodeHostPort. For the second and subsequent nodes, + set their helperHostPort to that of the first node. + durability controls the durability + guarantees made by the cluster. It is important that all nodes use the same value for this property. The default value is + NO_SYNC\,NO_SYNC\,SIMPLE_MAJORITY. Owing to the internal use of Apache Commons Config, it is currently necessary + to escape the commas within the durability string. + coalescingSync controls the coalescing-sync + mode of Qpid. It is important that all nodes use the same value. If omitted, it defaults to true. + The designatedPrimary is applicable only to the two-node + case. It governs the behaviour of a node when the other node fails or becomes uncontactable. If true, + the node will be designated as primary at startup and will be able to continue operating as a single node master. + If false, the node will transition to an unavailable state until a third-party manually designates the node as + primary or the other node is restored. It is suggested that the node that normally fulfils the role of master is + set true in config file and the node that is normally replica is set false. Be aware that setting both nodes to + true will lead to a failure to start up, as both cannot be designated at the point of contact. Designating both + nodes as primary at runtime (using the JMX interface) will lead to a split-brain + in the case of network partition and must be avoided. + Usage of domain names in helperHostPort and nodeHostPort is more preferebale + over IP addresses due to the tendency of more frequent changes of the last over the former. + If server IP address changes but domain name remains the same the HA cluster can continue working as normal + in case when domain names are used in cluster configuration. In case when IP addresses are used and they are changed with the time + than Qpid JMX API for HA can be used to change the addresses or remove the nodes from the cluster. + +
+ Passing BDB environment and replication configuration options + It is possible to pass BDB + environment and + replication configuration options from the virtualhost.xml. Environment configuration options are passed using + the envConfig element, and replication config using repConfig. + For example, to override the BDB environment configuration options je.cleaner.threads and + je.txn.timeout + + + je.cleaner.threads + 2 + + + je.txn.timeout + 15 min + + ... + ]]> + And to override the BDB replication configuration options je.rep.electionsPrimaryRetries. + + ... + + je.rep.electionsPrimaryRetries + 3 + + ... + ]]> +
+
+ +
+ Durability Guarantees + The term durability is used to mean that once a + transaction is committed, it remains committed regardless of subsequent failures. A highly durable system is one where + loss of a committed transaction is extermely unlikely, whereas with a less durable system loss of a transaction is likely + in a greater number of scenarios. Typically, the more highly durable a system the slower and more costly it will be. + Qpid exposes the all the + durability controls + offered by by BDB JE JA and a Qpid specific optimisation called coalescing-sync which defaults + to enabled. +
+ BDB Durability Controls + BDB expresses durability as a triplet with the following form: + ,,]]> + The sync polices controls whether the thread performing the committing thread awaits the successful completion of the + write, or the write and sync before continuing. The master sync policy and replica sync policy need not be the same. + For master and replic sync policies, the available values are: + SYNC, + WRITE_NO_SYNC, + NO_SYNC. SYNC + is offers the highest durability whereas NO_SYNC the lowest. + Note: the combination of a master sync policy of SYNC and coalescing-sync + true would result in poor performance with no corresponding increase in durability guarantee. It cannot not be used. + The acknowledgement policy defines whether when a master commits a transaction, it also awaits for the replica(s) to + commit the same transaction before continuing. For the two-node case, ALL and SIMPLE_MAJORITY are equal. + For acknowledgement policy, the available value are: + ALL, + SIMPLE_MAJORITY + NONE. +
+
+ Coalescing-sync + If enabled (the default) Qpid works to reduce the number of separate + file-system sync operations + performed by the master on the underlying storage device thus improving performance. It does + this coalescing separate sync operations arising from the different client commits operations occuring at approximately the same time. + It does this in such a manner not to reduce the ACID guarantees of the system. + Coalescing-sync has no effect on the behaviour of the replicas. +
+
+ Default + The default durability guarantee is NO_SYNC, NO_SYNC, SIMPLE_MAJORITY with coalescing-sync enabled. The effect + of this combination is described in the table below. It offers a good compromise between durability guarantee and performance + with writes being guaranteed on the master and the additional guarantee that a majority of replicas have received the + transaction. +
+
+ Examples + Here are some examples illustrating the effects of the durability and coalescing-sync settings. + + + Effect of different durability guarantees + + + + + Durability + Coalescing-sync + Description + + + + + 1 + NO_SYNC, NO_SYNC, SIMPLE_MAJORITY + true + Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of + coalescing-sync) and a majority of the replica(s) will have acknowledged the receipt + of the transaction. The replicas will write and sync the transaction to their disk at a point in the future governed by + ReplicationMutableConfig#LOG_FLUSH_INTERVAL. + + + + 2 + NO_SYNC, WRITE_NO_SYNC, SIMPLE_MAJORITY + true + Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of + coalescing-sync and a majority of the replica(s) will have acknowledged the write of + the transaction to their disk. The replicas will sync the transaction to disk at a point in the future with an upper bound governed by + ReplicationMutableConfig#LOG_FLUSH_INTERVAL. + + + 3 + NO_SYNC, NO_SYNC, NONE + false + After the commit returns to the client, the transaction is neither guaranteed to be written to the disk of the master + nor received by any of the replicas. The master and replicas will write and sync the transaction to their disk at a point + in the future with an upper bound governed by ReplicationMutableConfig#LOG_FLUSH_INTERVAL. This offers the weakest durability guarantee. + + + +
+ +
+
+ +
+ Client failover configuration + The details about format of Qpid connection URLs can be found at section + Connection URLs + of book Programming In Apache Qpid. + The failover policy option in the connection URL for the HA Cluster should be set to roundrobin. + The Master broker should be put into a first place in brokerlist URL option. + The recommended value for connectdelay option in broker URL should be set to + the value greater than 1000 milliseconds. If it is desired that clients re-connect automatically after a + master to replica failure, cyclecount should be tuned so that the retry period is longer than + the expected length of time to perform the failover. + Example of connection URL for the HA Cluster +
+ + +
+ Qpid JMX API for HA + Qpid exposes the BDB HA store information via its JMX interface and provides APIs to remove a Node from + the group, update a Node IP address, and assign a Node as the designated primary. + An instance of the BDBHAMessageStore MBean is instantiated by the broker for the each virtualhost using the HA store. + The reference to this MBean can be obtained via JMX API using an ObjectName like org.apache.qpid:type=BDBHAMessageStore,name="<virtualhost name>" + where <virtualhost name> is the name of a specific virtualhost on the broker. + + Mbean <classname>BDBHAMessageStore</classname> attributes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeAccessibilityDescription
GroupNameStringRead onlyName identifying the group
NodeNameStringRead onlyUnique name identifying the node within the group
NodeHostPortStringRead onlyHost/port used to replicate data between this node and others in the group
HelperHostPortStringRead onlyHost/port used to allow a new node to discover other group members
NodeStateStringRead onlyCurrent state of the node
ReplicationPolicyStringRead onlyNode replication durability
DesignatedPrimarybooleanRead/WriteDesignated primary flag. Applicable to the two node case.
CoalescingSyncbooleanRead onlyCoalescing sync flag. Applicable to the master sync policies NO_SYNC and WRITE_NO_SYNC only.
getAllNodesInGroupTabularDataRead onlyGet all nodes within the group, regardless of whether currently attached or not
+ + + Mbean <classname>BDBHAMessageStore</classname> operations + + + + + + + + + + + + + + + + + + + + + + +
OperationParametersReturnsDescription
removeNodeFromGroup + nodeName, name of node, string + voidRemove an existing node from the group
updateAddress + + + nodeName, name of node, string + + + newHostName, new host name, string + + + newPort, new port number, int + + + voidUpdate the address of another node. The node must be in a STOPPED state.
+
+ BDBHAMessageStore view from jconsole. + +
+ + Example of java code to get the node state value + environment = new HashMap(); + +// credentials: user name and password +environment.put(JMXConnector.CREDENTIALS, new String[] {"admin","admin"}); +JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9001/jmxrmi"); +JMXConnector jmxConnector = JMXConnectorFactory.connect(url, environment); +MBeanServerConnection mbsc = jmxConnector.getMBeanServerConnection(); + +ObjectName queueObjectName = new ObjectName("org.apache.qpid:type=BDBHAMessageStore,name=\"test\""); +String state = (String)mbsc.getAttribute(queueObjectName, "NodeState"); + +System.out.println("Node state:" + state); + ]]> + Example system output: + + +
+ +
+ Monitoring cluster + In order to discover potential issues with HA Cluster early, all nodes in the Cluster should be monitored on regular basis + using the following techniques: + + + Broker log files scrapping for WARN or ERROR entries and operational log entries like: + + + MST-1007 : Store Passivated. It can indicate that Master virtual host has gone down. + + + MST-1006 : Recovery Complete. It can indicate that a former Replica virtual host is up and became the Master. + + + + + Disk space usage and system load using system tools. + + + Berkeley HA node status using DbPing utility. + Using <classname>DbPing</classname> utility for monitoring HA nodes. +java -jar je-&oracleBdbProductVersion;.jar DbPing -groupName TestClusterGroup -nodeName Node-5001 -nodeHost localhost:5001 -socketTimeout 10000 + +Current state of node: Node-5001 from group: TestClusterGroup + Current state: MASTER + Current master: Node-5001 + Current JE version: &oracleBdbProductVersion; + Current log version: 8 + Current transaction end (abort or commit) VLSN: 165 + Current master transaction end (abort or commit) VLSN: 0 + Current active feeders on node: 0 + Current system load average: 0.35 + + In the example above DbPing utility requested status of Cluster node with name + Node-5001 from replication group TestClusterGroup running on host localhost:5001. + The state of the node was reported into a system output. + + + + Using Qpid broker JMX interfaces. + Mbean BDBHAMessageStore can be used to request the following node information: + + + NodeState indicates whether node is a Master or Replica. + + + Durability replication durability. + + + DesignatedPrimary indicates whether Master node is designated primary. + + + GroupName replication group name. + + + NodeName node name. + + + NodeHostPort node host and port. + + + HelperHostPort helper host and port. + + + AllNodesInGroup lists of all nodes in the replication group including their names, hosts and ports. + + + For more details about BDBHAMessageStore MBean please refer section Qpid JMX API for HA + + +
+ +
+ Disk space requirements + Disk space is a critical resource for the HA Qpid broker. + In case when a Replica goes down (or falls behind the Master in 2 node cluster where the Master is designated primary) + and the Master continues running, the non-replicated store files are kept on the Masters disk for the period of time + as specified in je.rep.repStreamTimeout JE setting in order to replicate this data later + when the Replica is back. This setting is set to 1 hour by default by the broker. The setting can be overridden as described in + . + Depending from the application publishing/consuming rates and message sizes, + the disk space might become overfull during this period of time due to preserved logs. + Please, make sure to allocate enough space on your disk to avoid this from happening. + +
+ +
+ Network Requirements + The HA Cluster performance depends on the network bandwidth, its use by existing traffic, and quality of service. + In order to achieve the best performance it is recommended to use a separate network infrastructure for the Qpid HA Nodes + which might include installation of dedicated network hardware on Broker hosts, assigning a higher priority to replication ports, + installing a cluster in a separate network not impacted by any other traffic. +
+ +
+ Security + At the moment Berkeley replication API supports only TCP/IP protocol to transfer replication data between Master and Replicas. + As result, the replicated data is unprotected and can be intercepted by anyone having access to the replication network. + Also, anyone who can access to this network can introduce a new node and therefore receive a copy of the data. + In order to reduce the security risks the entire HA cluster is recommended to run in a separate network protected from general access. +
+ +
+ Backups + In order to protect the entire cluster from some cataclysms which might destroy all cluster nodes, + backups of the Master store should be taken on a regular basis. + Qpid Broker distribution includes the "hot" backup utility backup.sh which can be found at broker bin folder. + This utility can perform the backup when broker is running. + backup.sh script invokes org.apache.qpid.server.store.berkeleydb.BDBBackup to do the job. + You can also run this class from command line like in an example below: + Performing store backup by using <classname>BDBBackup</classname> class directly + java -cp qpid-bdbstore-0.18.jar org.apache.qpid.server.store.berkeleydb.BDBBackup -fromdir path/to/store/folder -todir path/to/backup/foldeAr + + In the example above BDBBackup utility is called from qpid-bdbstore-0.18.jar to backup the store at path/to/store/folder and copy store logs into path/to/backup/folder. + Linux and Unix users can take advantage of backup.sh bash script by running this script in a similar way. + Performing store backup by using <classname>backup.sh</classname> bash script + backup.sh -fromdir path/to/store/folder -todir path/to/backup/folder + + + Do not forget to ensure that the Master store is being backed up, in the event the Node elected Master changes during + the lifecycle of the cluster. + +
+ +
+ Migration of a non-HA store to HA + Non HA stores starting from schema version 4 (0.14 Qpid release) can be automatically converted into HA store on broker startup if replication is first enabled with the DbEnableReplication utility from the BDB JE jar. + DbEnableReplication converts a non HA store into an HA store and can be used as follows: + Enabling replication +java -jar je-&oracleBdbProductVersion;.jar DbEnableReplication -h /path/to/store -groupName MyReplicationGroup -nodeName MyNode1 -nodeHostPort localhost:5001 + + In the examples above, je jar of version &oracleBdbProductVersion; is used to convert store at /path/to/store into HA store having replication group name MyReplicationGroup, node name MyNode1 and running on host localhost and port 5001. + After running DbEnableReplication and updating the virtual host store to configuration to be an HA message store, like in example below, + on broker start up the store schema will be upgraded to the most recent version and the broker can be used as normal. + + Example of XML configuration for HA message store + + org.apache.qpid.server.store.berkeleydb.BDBHAMessageStore + /path/to/store + + MyReplicationGroup + MyNode1 + localhost:5001 + localhost:5001 + +]]> + + The Replica nodes can be started with empty stores. The data will be automatically copied from Master to Replica on Replica start-up. + This will take a period of time determined by the size of the Masters store and the network bandwidth between the nodes. + + Due to existing caveats in Berkeley JE with copying of data from Master into Replica it is recommended to restart the Master node after store schema upgrade is finished before starting the Replica nodes. + +
+ +
+ Disaster Recovery + This section describes the steps required to restore HA broker cluster from backup. + The detailed instructions how to perform backup on replicated environment can be found here. + At this point we assume that backups are collected on regular basis from Master node. + Replication configuration of a cluster is stored internally in HA message store. + This information includes IP addresses of the nodes. + In case when HA message store needs to be restored on a different host with a different IP address + the cluster replication configuration should be reseted in this case + Oracle provides a command line utility DbResetRepGroup + to reset the members of a replication group and replace the group with a new group consisting of a single new member + as described by the arguments supplied to the utility + Cluster can be restored with the following steps: + + Copy log files into the store folder from backup + + Use DbResetRepGroup to reset an existing environment. See an example below + + Reseting of replication group with <classname>DbResetRepGroup</classname> +java -cp je-&oracleBdbProductVersion;.jar com.sleepycat.je.rep.util.DbResetRepGroup -h ha-work/Node-5001/bdbstore -groupName TestClusterGroup -nodeName Node-5001 -nodeHostPort localhost:5001 + + In the example above DbResetRepGroup utility from Berkeley JE of version &oracleBdbProductVersion; is used to reset the store + at location ha-work/Node-5001/bdbstore and set a replication group to TestClusterGroup + having a node Node-5001 which runs at localhost:5001. + + Start a broker with HA store configured as specified on running of DbResetRepGroup utility. + Start replica nodes having the same replication group and a helper host port pointing to a new master. The store content will be copied into Replicas from Master on their start up. + +
+ +
+ Performance + The aim of this section is not to provide exact performance metrics relating to HA, as this depends heavily on the test + environment, but rather showing an impact of HA on Qpid broker performance in comparison with the Non HA case. + For testing of impact of HA on a broker performance a special test script was written using Qpid performance test framework. + The script opened a number of connections to the Qpid broker, created producers and consumers on separate connections, + and published test messages with concurrent producers into a test queue and consumed them with concurrent consumers. + The table below shows the number of producers/consumers used in the tests. + The overall throughput was collected for each configuration. + + + Number of producers/consumers in performance tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TestNumber of producersNumber of consumers
111
222
344
488
51616
63232
76464
+ The test was run against the following Qpid Broker configurations + + + Non HA Broker + + + HA 2 Nodes Cluster with durability SYNC,SYNC,ALL + + + HA 2 Nodes Cluster with durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL + + + HA 2 Nodes Cluster with durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL and coalescing-sync Qpid mode + + + HA 2 Nodes Cluster with durability WRITE_NO_SYNC,NO_SYNC,ALL and coalescing-sync Qpid mode + + + HA 2 Nodes Cluster with durability NO_SYNC,NO_SYNC,ALL and coalescing-sync Qpid option + + + The evironment used in testing consisted of 2 servers with 4 CPU cores (2x Intel(r) Xeon(R) CPU 5150@2.66GHz), 4GB of RAM + and running under OS Red Hat Enterprise Linux AS release 4 (Nahant Update 4). Network bandwidth was 1Gbit. + + We ran Master node on the first server and Replica and clients(both consumers and producers) on the second server. + In non-HA case Qpid Broker was run on a first server and clients were run on a second server. + The table below contains the test results we measured on this environment for different Broker configurations. + Each result is represented by throughput value in KB/second and difference in % between HA configuration and non HA case for the same number of clients. + + Performance Comparison + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test/BrokerNo HASYNC, SYNC, ALLWRITE_NO_SYNC, WRITE_NO_SYNC, ALLWRITE_NO_SYNC, WRITE_NO_SYNC, ALL - coalescing-syncWRITE_NO_SYNC, NO_SYNC,ALL - coalescing-syncNO_SYNC, NO_SYNC, ALL - coalescing-sync
1 (1/1)0.0%-61.4%117.0%-16.02%-9.58%-25.47%
2 (2/2)0.0%-75.43%67.87%-66.6%-69.02%-30.43%
3 (4/4)0.0%-84.89%24.19%-71.02%-69.37%-43.67%
4 (8/8)0.0%-91.17%-22.97%-82.32%-83.42%-55.5%
5 (16/16)0.0%-91.16%-21.42%-86.6%-86.37%-46.99%
6 (32/32)0.0%-94.83%-51.51%-92.15%-92.02%-57.59%
7 (64/64)0.0%-94.2%-41.84%-89.55%-89.55%-50.54%
+ The figure below depicts the graphs for the performance test results +
+ Test results + +
+ On using durability SYNC,SYNC,ALL (without coalescing-sync) the performance drops significantly (by 62-95%) in comparison with non HA broker. + Whilst, on using durability WRITE_NO_SYNC,WRITE_NO_SYNC,ALL (without coalescing-sync) the performance drops by only half, but with loss of durability guarantee, so is not recommended. + In order to have better performance with HA, Qpid Broker comes up with the special mode called coalescing-sync, + With this mode enabled, Qpid broker batches the concurrent transaction commits and syncs transaction data into Master disk in one go. + As result, the HA performance only drops by 25-60% for durability NO_SYNC,NO_SYNC,ALL and by 10-90% for WRITE_NO_SYNC,WRITE_NO_SYNC,ALL. +
+ + diff --git a/doc/book/src/java-broker/Java-Broker-Installation.xml b/doc/book/src/java-broker/Java-Broker-Installation.xml new file mode 100644 index 0000000000..218e39f578 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Installation.xml @@ -0,0 +1,185 @@ + + +%entities; +]> + + + + Installation +
+ Introduction + This document describes how to install the Java Broker on both Windows and UNIX + platforms. +
+
+ Prerequisites +
+ Java Platform + + The Java Broker is an 100% Java implementation and as such it can be used on any operating + system supporting Java 1.6 or higher. This includes Linux, Solaris, Mac OS X, and Windows XP/Vista/7/8. + + The broker has been tested with Java implementations from both Oracle and IBM. Whatever + platform you chose, it is recommended that you ensure it is patched with any critical updates made + available from the vendor. + + + Verify that your JVM is installed properly by following these instructions. + +
+
+ Disk + The Java Broker installation requires approximately 20MB of free disk space. + The Java Broker also requires a working directory. The working directory is used for + the message store, that is, the area of the file-system used to record persistent messages whilst they + are passing through the Broker. The working directory is also used for the default location of the log file. + The size of the working directory will depend on the how the Broker is used. + The performance of the file system hosting the work directory is key to the performance of Broker as + a whole. For best performance, choose a device that has low latency and one that is uncontended by other + applications. + Be aware that there are additional considerations if you are considering hosting the working directory on NFS. See + for further details. +
+
+ Memory + Qpid caches messages on the heap for performance reasons, so in general, the Broker will + benefit from as much heap as possible. However, on a 32bit JVM, the maximum addressable memory range + for a process is 4GB, after leaving space for the JVM's own use this will give a maximum heap size + of approximately ~3.7GB. +
+
+ Operating System Account + Installation or operation of Qpid does not require a privileged account (i.e. root + on UNIX platforms or Administrator on Windows). However it is suggested that you use an dedicated account + (e.g. qpid) for the installation and operation of the Java Broker. +
+
+ +
+ Download +
+ Broker Release + You can download the latest qpid-java-broker-&qpidCurrentRelease;.tar.gz package from the Download Page. + + It is recommended that you confirm the integrity of the download by verifying the PGP signature + matches that available on the site. Instrutions are given on the download page. + +
+
+ Optional Dependencies + The broker has an optional message store implementations backed by Oracle BDB JE. If you wish to use these + stores you will need to provide the optional Oracle BDB JE dependency. For more details, see + +
+
+ +
+ Installation on Windows + + Firstly, verify that your JVM is installed properly by following + these instructions. + + Now chose a directory for Qpid broker installation. This directory will be used for the Qpid JARs and configuration files. + It need not be the same location as the store used for the persistent messages or the log file (you will chose this + location later). For the remainder this example we will assumed that location c:\qpid has been chosen. + Now using WinZipWinZip is a Registered Trademark of WinZip International LLC (or similar) + extract the Qpid package qpid-java-broker-&qpidCurrentRelease;.tar.gz into the directory. + The extraction of the Qpid package will have created a directory qpid-broker-&qpidCurrentRelease; within c:\qpid + Volume in drive C has no label + + Directory of c:\qpid\qpid-broker-&qpidCurrentRelease; + +07/25/2012 11:22 PM . +09/30/2012 10:51 AM .. +09/30/2012 12:24 AM bin +08/21/2012 11:17 PM etc +07/25/2012 11:22 PM lib +07/20/2012 08:10 PM 65,925 LICENSE +07/20/2012 08:10 PM 3,858 NOTICE +07/20/2012 08:10 PM 1,346 README.txt + 3 File(s) 71,129 bytes + 5 Dir(s) 743,228,796,928 bytes free +
+ Setting the working directory + Qpid requires a work directory. This directory is used for the default location of the Qpid log + file and is used for the storage of persistent messages. The work directory can be set on the + command-line (for the lifetime of the command interpreter), but you will normally want to set + the environment variable permanently via the Advanced System Settings in the Control Panel. + set QPID_WORK=S:\qpidwork + If the directory referred to by QPID_WORK does not exist, the Java Broker will attempt to create it + on start-up. +
+
+ Optional Dependencies + The broker has an optional message store implementations backed by Oracle BDB JE. If you wish to use these + stores you will need to provide the optional Oracle BDB JE dependency. For more details, see + +
+
+ +
+ Installation on UNIX platforms + + Firstly, verify that your JVM is installed properly by following + these instructions. + + Now chose a directory for Qpid broker installation. This directory will be used for the Qpid JARs and configuration files. + It need not be the same location as the store used for the persistent messages or the log file (you will chose this + location later). For the remainder this example we will assumed that location /usr/local/qpid has been chosen. + Extract the Qpid package qpid-java-broker-&qpidCurrentRelease;.tar.gz into the directory. + mkdir /usr/local/qpid +cd /usr/local/qpid +tar xvzf qpid-java-broker-&qpidCurrentRelease;.tar.gz> + The extraction of the Qpid package will have created a directory qpid-broker-x.x + ls -la qpid-broker-&qpidCurrentRelease;/ +total 152 +drwxr-xr-x 8 qpid qpid 272 25 Jul 23:22 . +drwxr-xr-x 45 qpid qpid 1530 30 Sep 10:51 .. +-rw-r--r--@ 1 qpid qpid 65925 20 Jul 20:10 LICENSE +-rw-r--r--@ 1 qpid qpid 3858 20 Jul 20:10 NOTICE +-rw-r--r--@ 1 qpid qpid 1346 20 Jul 20:10 README.txt +drwxr-xr-x 10 qpid qpid 340 30 Sep 00:24 bin +drwxr-xr-x 9 qpid qpid 306 21 Aug 23:17 etc +drwxr-xr-x 34 qpid qpid 1156 25 Jul 23:22 lib + +
+ Setting the working directory + Qpid requires a work directory. This directory is used for the default location of the Qpid log + file and is used for the storage of persistent messages. The work directory can be set on the + command-line (for the lifetime of the current shell), but you will normally want to set + the environment variable permanently the user's shell profile file (~/.bash_profile for Bash etc). + + + If the directory referred to by QPID_WORK does not exist, the Java Broker will attempt to create it + on start-up. + +
+
+ Optional Dependencies + The broker has an optional message store implementations backed by Oracle BDB JE. If you wish to use these + stores you will need to provide the optional Oracle BDB JE dependency. For more details, see + +
+
+ diff --git a/doc/book/src/java-broker/Java-Broker-Introduction.xml b/doc/book/src/java-broker/Java-Broker-Introduction.xml new file mode 100644 index 0000000000..651389d0ac --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Introduction.xml @@ -0,0 +1,89 @@ + + +%entities; +]> + + + + Introduction + The Java Broker is a powerful open-source message broker that implements all versions of the + Advanced Message Queuing Protocol (AMQP). The Java + Broker is actually one of two message brokers provided by the Apache Qpid project: the Java Broker and the C++ + Broker. + This document relates to the Java Broker. The C++ Broker is + described separately. + Headline features + + + 100% Java implementation - runs on any platform supporting Java 1.6 or higher + + + Messaging clients support in Java, C++, Python. + + + JMS 1.1 compliance (Java client). + + + Persistent and non-persistent (transient) message support + + + Supports for all common messaging patterns (point-to-point, publish/subscribe, fan-out + etc). + + + Transaction support including XA + XA provided when using AMQP 0-10 + + + + Supports for all versions of the AMQP protocol + + + Automatic message translation, allowing clients using different AMQP versions to communicate with each other. + + + Pluggable authentication architecture with out-of-the-box support for Kerberos, LDAP, + External, and file-based authentication mechanisms. + + + Pluggable message store architecture with implementations based on Apache Derby, Oracle BDB JE + Oracle BDB JE must be downloaded separately. + , and Memory Store + + + Web based management interface and programmatic management interfaces via REST and JMX + APIs. + + + SSL support + + + High availability (HA) support. + HA currently only available to users of the optional BDB JE HA based message store. + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Miscellaneous.xml b/doc/book/src/java-broker/Java-Broker-Miscellaneous.xml new file mode 100644 index 0000000000..007d6cde5b --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Miscellaneous.xml @@ -0,0 +1,80 @@ + + +%entities; +]> + + + + Miscellaneous + +
+ JVM Installation verification +
+ Verify JVM on Windows + + Firstly confirm that the JAVA_HOME environment variable is set correctly by typing the + following at the command prompt: + + + + If JAVA_HOME is set you will see something similar to the following: + + + + + Then confirm that a Java installation (1.6 or higher) is available: + + + + If java is available on the path, output similar to the following will be seen: + + +
+ +
+ Verify JVM on Windows + + Firstly confirm that the JAVA_HOME environment variable is set correctly by typing the + following at the command prompt: + + + + If JAVA_HOME is set you will see something similar to the following: + + + + + Then confirm that a Java installation (1.6 or higher) is available: + + + + If java is available on the path, output similar to the following will be seen: + + +
+
+ diff --git a/doc/book/src/java-broker/Java-Broker-Queues-Messaging-Groups.xml b/doc/book/src/java-broker/Java-Broker-Queues-Messaging-Groups.xml new file mode 100644 index 0000000000..60413282a0 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Queues-Messaging-Groups.xml @@ -0,0 +1,26 @@ + + + +
+Messaging Groups + +
diff --git a/doc/book/src/java-broker/Java-Broker-Queues-OtherTypes.xml b/doc/book/src/java-broker/Java-Broker-Queues-OtherTypes.xml new file mode 100644 index 0000000000..471d73f283 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Queues-OtherTypes.xml @@ -0,0 +1,276 @@ + + +%entities; +]> + + +
+ Other Queue Types + +
+ Introduction + In addition to the standard queue type where messages are delivered in the same order + that they were sent, the Java Broker supports three additional queue types which allows for + alternative delivery behaviours. These are priority-queues, sorted-queues-, and + last-value-queues (LVQs). + In the following sections, the semantics of each queue type is described, followed by a + description of how instances of these queue can be created via configuration or programmatically. + The final section discusses the importance of using a low client pre-fetch with these queued. + +
+ +
+ Priority Queues + In a priority queue, messages on the queue are delivered in an order determined by the + JMS priority message + header within the message. By default Qpid supports the 10 priority levels mandated + by JMS, with priority value 0 as the lowest priority and 9 as the highest. + It is possible to reduce the effective number of priorities if desired. + JMS defines the + default message priority as 4. Messages sent without a specified priority use this + default. +
+
+ Sorted Queues + Sorted queues allow the message delivery order to be determined by value of an arbitrary + JMS message + property. Sort order is alpha-numeric and the property value must have a type + java.lang.String. + Messages sent to a sorted queue without the specified JMS message property will be + inserted into the 'last' position in the queue. +
+
+ Last Value Queues (LVQ) + LVQs (or conflation queues) are special queues that automatically discard any message when + a newer message arrives with the same key value. The key is specified by arbitrary JMS message + property. + An example of an LVQ might be where a queue represents prices on a stock exchange: when + you first consume from the queue you get the latest quote for each stock, and then as new + prices come in you are sent only these updates. + Like other queues, LVQs can either be browsed or consumed from. When browsing an + individual subscriber does not remove the message from the queue when receiving it. This + allows for many subscriptions to browse the same LVQ (i.e. you do not need to create and bind + a separate LVQ for each subscriber who wishes to receive the contents of the LVQ). + Messages sent to an LVQ without the specified property will be delivered as normal and + will never be "replaced". +
+
+ Creating a Priority, Sorted or LVQ Queue + To create a priority, sorted or LVQ queue, it can be defined in the virtualhost + configuration file, or the queue can be created programmtically from a client via AMQP (using + an extension to JMS), or using JMX. These methods are described below. + Once a queue is created you cannot change its type (without deleting it and re-creating). + Also note you cannot currently mix the natures of these queue types, for instance, you cannot + define a queue which it both an LVQ and a priority-queue. +
+ Using configuration + To create a priority, sorted or LVQ queue within configuration, add the appropriate xml + to the virtualhost.xml configuration file within the queues + element. +
+ Priority + To defining a priority queue, add a <priority>true</priority> element. By + default the queue will have 10 distinct priorities. + + Configuring a priority queue + + myqueue + + amq.direct + true + +]]> + + If you require fewer priorities, it is possible to specify a + priorities element (whose value is a integer value between 2 and 10 + inclusive) which will give the queue that number of distinct priorities. When messages are + sent to that queue, their effective priority will be calculated by partitioning the + priority space. If the number of effective priorities is 2, then messages with priority + 0-4 are treated the same as "lower priority" and messages with priority 5-9 are treated + equivalently as "higher priority". + + Configuring a priority queue with fewer priorities + + myqueue + + amq.direct + true + 4 + +]]> + +
+
+ Sorted + To define a sorted queue, add a sortKey element. The value of the + sortKey element defines the message property to use the value of when + sorting the messages put onto the queue. + + Configuring a sorted queue + + myqueue + + amq.direct + message-property-to-sort-by + +]]> + +
+
+ LVQ + To define a LVQ, add a lvq element with the value + true. Without any further configuration this will define an LVQ + which uses the JMS message property qpid.LVQ_key as the key for + replacement. + + Configuring a LVQ queue + + myqueue + + amq.direct + true + +]]> + + If you wish to define your own property then you can do so using the + lvqKey element. + + Configuring a LVQ queue with custom message property name + + myqueue + + amq.direct + true + ISIN + +]]> + +
+
+
+ Using JMX or AMQP + To create a priority, sorted or LVQ queue programmatically from JMX or using a Qpid + extension to JMS, pass the appropriate queue-declare arguments. + + Queue-declare arguments understood for priority, sorted and LVQ queues + + + + Queue type + Argument name + Argument name + Argument Description + + + + + priority + priorities + java.lang.Integer + Specifies a priority queue with given number priorities + + + sorted + qpid.queue_sort_key + java.lang.String + Specifies sorted queue with given message property used to sort the + entries + + + lvq + qpid.last_value_queue_key + java.lang.String + Specifies lvq queue with given message property used to conflate the + entries + + + +
+ The following example illustrates the creation of the a LVQ queue from a + javax.jms.Session object. Note that this utilises a Qpid specific extension to JMS and + involves casting the session object back to its Qpid base-class. + + Creation of an LVQ using the Qpid extension to JMS + arguments = new HashMap(); +arguments.put("qpid.last_value_queue_key","ISIN"); +((AMQSession) session).createQueue(queueName, autoDelete, durable, exclusive, arguments);]]> + + + The following example illustrates the creation of the sorted queue from a the JMX + interface using the ManagedBroker interface. + + Creation of a sorted queue using JMX + environment = new HashMap(); +environment.put(JMXConnector.CREDENTIALS, new String[] {"admin","password"}); +// Connect to service +JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi"); +JMXConnector jmxConnector = JMXConnectorFactory.connect(url, environment); +MBeanServerConnection mbsc = jmxConnector.getMBeanServerConnection(); +// Object name for ManagedBroker for virtualhost myvhost +ObjectName objectName = new ObjectName("org.apache.qpid:type=VirtualHost.VirtualHostManager,VirtualHost=myvhost"); +// Get the ManagedBroker object +ManagedBroker managedBroker = JMX.newMBeanProxy(mbsc, objectName, ManagedBroker.class);; + +// Create the queue passing arguments +Map arguments = new HashMap(); +arguments.put("qpid.queue_sort_key","myheader"); +managedBroker.createNewQueue("myqueue", null, true, arguments);]]> + +
+
+ +
+ Low pre-fetch + Qpid clients receive buffered messages in batches, sized according to the pre-fetch value. + The current default is 500. + However, if you use the default value you will probably not see + desirable behaviour when using priority, sorted or lvq queues. Once the broker has sent a + message to the client its delivery order is then fixed, regardless of the special behaviour of + the queue. + For example, if using a priority queue and a prefetch of 100, and 100 messages arrive with + priority 2, the broker will send these messages to the client. If then a new message arrives + will priority 1, the broker cannot leap frog messages of lower priority. The priority 1 will + be delivered at the front of the next batch of messages to be sent to the client. + So, you need to set the prefetch values for your client (consumer) to make this sensible. + To do this set the Java system property max_prefetch on the client + environment (using -D) before creating your consumer. + A default for all client connections can be set via a system property: + +-Dmax_prefetch=1 + + The prefetch can be also be adjusted on a per connection basis by adding a + maxprefetch value to the Connection URLs + + +amqp://guest:guest@client1/development?maxprefetch='1'&brokerlist='tcp://localhost:5672' + + Setting the Qpid pre-fetch to 1 will give exact queue-type semantics as perceived by the + client however, this brings a performance cost. You could test with a slightly higher + pre-fetch to trade-off between throughput and exact semantics. +
+
diff --git a/doc/book/src/java-broker/Java-Broker-Queues.xml b/doc/book/src/java-broker/Java-Broker-Queues.xml new file mode 100644 index 0000000000..050d4cdbce --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Queues.xml @@ -0,0 +1,27 @@ + + + + + Queues + + + diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Alerts.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Alerts.xml new file mode 100644 index 0000000000..29ac68b937 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Alerts.xml @@ -0,0 +1,26 @@ + + + +
+Alerts + +
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control.xml new file mode 100644 index 0000000000..8db014a6b7 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control.xml @@ -0,0 +1,228 @@ + + + +
+ Producer Flow Control + +
+ General Information + + The Qpid 0.6 release introduced a simplistic producer-side flow control mechanism + into the Java Messaging Broker, causing producers to be flow-controlled when they + attempt to send messages to an overfull queue. Qpid 0.18 introduced a similar + mechanism triggered by an overfull persistent message store on a virtual host. + +
+
+ Server Configuration +
+ Configuring a Queue to use flow control + + Flow control is enabled on a producer when it sends a message to a Queue + which is "overfull". The producer flow control will be rescinded when all + Queues on which a producer is blocking become "underfull". A Queue is defined + as overfull when the size (in bytes) of the messages on the queue exceeds the + "capacity" of the Queue. A Queue becomes "underfull" when its size becomes + less than the "flowResumeCapacity". + + + + Configuring a queue depth limit + + + test + + amq.direct + 10485760 + 8388608 + + + ]]> + + + + The default for all queues on a virtual host can also be set + + + Configuring a default queue depth limit on a virtualhost + + + + localhost + + 10485760 + 8388608 + + + + ]]> + + + + Where no flowResumeCapacity is set, the flowResumeCapacity is set to be equal + to the capacity. Where no capacity is set, capacity is defaulted to 0 meaning + there is no capacity limit. + +
+ Broker Log Messages + + There are four new Broker log messages that may occur if flow control through queue capacity limits is enabled. + Firstly, when a capacity limited queue becomes overfull, a log message similar to the following is produced + + +MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1003 : Overfull : Size : 1,200 bytes, Capacity : 1,000 + + Then for each channel which becomes blocked upon the overful queue a log message similar to the following is produced: + +MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1005 : Flow Control Enforced (Queue MyQueue) + + When enough messages have been consumed from the queue that it becomes underfull, then the following log is generated: + +MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1004 : Underfull : Size : 600 bytes, Resume Capacity : 800 + + And for every channel which becomes unblocked you will see a message similar to: + +MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1006 : Flow Control Removed + + Obviously the details of connection, virtual host, queue, size, capacity, etc would depend on the configuration in use. + + +
+
+ +
+ Disk quota-based flow control + + Since version 0.18 of Qpid Broker, flow control can be triggered when a + configured disk quota is exceeded. This is supported by the BDB and Derby message stores. + + + This functionality blocks all producers on reaching the disk overflow limit. When consumers + consume the messages, causing disk space usage to falls below the underflow limit, the + producers are unblocked and continue working as normal. + + + Two limits can be configured: + + + overfull limit - the maximum space on disk (in bytes) which can be used by store. + + + underfull limit - when the space on disk drops below this limit, producers are allowed to resume publishing. + + + An example of quota configuration for the BDB message store is provided below. + + + + Configuring a limit on a store + + + org.apache.qpid.server.store.berkeleydb.BDBMessageStore + ${work}/bdbstore/test + 50000000 + 45000000 + + ]]> + + + + The disk quota functionality is based on "best effort" principle. This means the broker + cannot guarantee that the disk space limit will not be exceeded. If several concurrent + transactions are started before the limit is reached, which collectively cause the limit + to be exceeded, the broker may allow all of them to be committed. + + +
+ Broker Log Messages for quota flow control + + There are 2 new broker log messages that may occur if flow control through disk quota limits is enabled. + When the virtual host is blocked due to exceeding of the disk quota limit the following message + appears in the broker log + +[vh(/test)/ms(BDBMessageStore)] MST-1008 : Store overfull, flow control will be enforced + + When virtual host is unblocked after cleaning the disk space the following message appears in the broker log + +[vh(/test)/ms(BDBMessageStore)] MST-1009 : Store overfull condition cleared + + +
+
+
+ + +
+ Client impact and configuration + + If a producer sends to a queue which is overfull, the broker will respond by + instructing the client not to send any more messages. The impact of this is + that any future attempts to send will block until the broker rescinds the flow control order. + + + While blocking the client will periodically log the fact that it is blocked waiting on flow control. + + +WARN Message send delayed by 5s due to broker enforced flow control +WARN Message send delayed by 10s due to broker enforced flow control + + + After a set period the send will timeout and throw a JMSException to the calling code. + + + If such a JMSException is thrown, the message will not be sent to the broker, + however the underlying Session may still be active - in particular if the + Session is transactional then the current transaction will not be automatically + rolled back. Users may choose to either attempt to resend the message, or to + roll back any transactional work and close the Session. + + + Both the timeout delay and the periodicity of the warning messages can be set + using Java system properties. + + + The amount of time (in milliseconds) to wait before timing out + is controlled by the property qpid.flow_control_wait_failure. + + + The frequency at which the log message informing that the producer is flow + controlled is sent is controlled by the system property qpid.flow_control_wait_notify_period. + + + Adding the following to the command line to start the client would result in a timeout of one minute, + with warning messages every ten seconds: + + +-Dqpid.flow_control_wait_failure=60000 +-Dqpid.flow_control_wait_notify_period=10000 + +
+ Older Clients + + The flow control feature was first added to the Java broker/client in the 0.6 release. If an older client connects to the broker then the flow control commands will be ignored by it and it will not be blocked. So to fully benefit from this feature both Client and Broker need to be at least version 0.6. + +
+
+
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management.xml new file mode 100644 index 0000000000..814b366d9d --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Disk-Space-Management.xml @@ -0,0 +1,27 @@ + + + +
+ Disk Space Management + + +
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Handling-Undeliverable-Messages.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Handling-Undeliverable-Messages.xml new file mode 100644 index 0000000000..40c0e44629 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Handling-Undeliverable-Messages.xml @@ -0,0 +1,169 @@ + + +%entities; +]> + + +
+ Handing Undeliverable Messages + +
+ Introduction + Messages that cannot be delivered successfully to a consumer (for instance, because the + client is using a transacted session and rolls-back the transaction) can be made available on + the queue again and then subsequently be redelivered, depending on the precise session + acknowledgement mode and messaging model used by the application. This is normally desirable + behaviour that contributes to the ability of a system to withstand unexpected errors. However, it + leaves open the possibility for a message to be repeatedly redelivered (potentially indefinitely), + consuming system resources and preventing the delivery of other messages. Such undeliverable + messages are sometimes known as poison messages. + For an example, consider a stock ticker application that has been designed to consume prices + contained within JMS TextMessages. What if inadvertently a BytesMessage is placed onto the queue? + As the ticker application does not expect the BytesMessage, its processing might fail and cause it + to roll-back the transaction, however the default behavior of the Broker would mean that the + BytesMessage would be delivered over and over again, preventing the delivery of other legitimate + messages, until an operator intervenes and removes the erroneous message from the queue. + Qpid has maximum delivery count and dead-letter queue (DLQ) features which can be used in + concert to construct a system that automatically handles such a condition. These features are + described in the following sections. +
+ +
+ Maximum Delivery Count + Maximum delivery count is a property of a queue. If a consumer application is unable to + process a message more than the specified number of times, then the broker will either route the + message to a dead-letter queue (if one has been defined), or will discard the message. + In order for a maximum delivery count to be enforced, the consuming client + must call Session#rollback() (or Session#recover() if the session is not transacted). It is during the Broker's + processing of Session#rollback() (or Session#recover()) that if a message has been seen + at least the maximum number of times then it will move the message to the DLQ or discard the + message. + If the consuming client fails in another manner, for instance, closes the connection, the + message will not be re-routed and consumer application will see the same poison message again + once it reconnects. + If the consuming application is using AMQP 0-9-1, 0-9, or 0-8 protocols, it is necessary to + set the client system property qpid.reject.behaviour or connection or binding + URL option rejectbehaviour to the value system. + It is possible to determine the number of times a message has been sent to a consumer via + the Management interfaces, but is not possible to determine this information from a message client. + Specifically, the optional JMS message header JMSXDeliveryCount is not + supported. + Maximum Delivery Count can be enabled via management (see ) using the the queue declare property + x-qpid-maximum-delivery-count or via configuration + as illustrated below. +
+ +
+ Dead Letter Queues (DLQ) + A Dead Letter Queue (DLQ) acts as an destination for messages that have somehow exceeded the + normal bounds of processing and is utilised to prevent disruption to flow of other messages. When + a DLQ is enabled for a given queue if a consuming client indicates it no longer wishes the + receive the message (typically by exceeding a Maximum Delivery Count) then the message is moved + onto the DLQ and removed from the original queue. + The DLQ feature causes generation of a Dead Letter Exchange and a Dead Letter Queue. These + are named convention QueueName_DLE and QueueName_DLQ. + DLQs can be enabled via management (see ) using the queue declare property x-qpid-dlq-enabled or via configuration + as illustrated below. + + Avoid excessive queue depth + Applications making use of DLQs should make provision for the frequent + examination of messages arriving on DLQs so that both corrective actions can be taken to resolve + the underlying cause and organise for their timely removal from the DLQ. Messages on DLQs + consume system resources in the same manner as messages on normal queues so excessive queue + depths should not be permitted to develop. + +
+ +
+ Configuration + In the below configuration it can be seen that DLQs/Maximum Delivery Count are enabled at + the broker level with maximum delivery count set to 5, disabled at the virtualhost level for the + 'dev-only' virtualhost, and enabled specifically for the 'dev-only-main-queue' with maximum + delivery count overridden to 5. + As 'dev-only-main-queue' has its own configuration specified, this value overrides all + others and causes the features to be enabled for this queue. In contrast to this, + 'dev-only-other-queue' does not specify its own value and picks up the false value specified for + its parent virtualhost, causing the DLQ/Maximum Delivery Count features to be disabled for this + queue. Any such queue in the 'dev-only' virtualhost which does not specify its own configuration + value will have the DLQ/Maximum Delivery Count feature disabled. + The queue 'localhost-queue' has the DLQ/Maximum Delivery Count features enabled, as neither + the queue itself or the 'localhost' virtualhost specifies a configuration value and so the broker + level value of true is used. Any such queue in the 'localhost' virtualhost which does not specify + its own configuration value will have the features enabled. + + Enabling DLQs and maximum delivery count at broker level within config.xml + + ... + true + 5 + ... +]]> + + + Enabling DLQs and maximum delivery count at virtualhost and queue level within + virtualhosts.xml + + ... + + dev-only + + + false + 0 + + dev-only-main-queue + + true + 3 + + + + dev-only-other-queue + + + + + + localhost + + + + localhost-queue + + + + + ... +]]> + + +
+ + +
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Log-Files.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Log-Files.xml new file mode 100644 index 0000000000..84ee4db6d3 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Log-Files.xml @@ -0,0 +1,26 @@ + + + +
+Log Files + +
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime-Producer-Transaction-Timeout.xml b/doc/book/src/java-broker/Java-Broker-Runtime-Producer-Transaction-Timeout.xml new file mode 100644 index 0000000000..04212d94ed --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime-Producer-Transaction-Timeout.xml @@ -0,0 +1,181 @@ + + +%entities; +]> + + +
+ Producer Transaction Timeout +
+ General Information + The transaction timeout mechanism is used to control broker resources when clients + producing messages using transactional sessions hang or otherwise become unresponsive, or simply + begin a transaction and keep using it without ever calling Session#commit(). + Users can choose to configure an idleWarn or openWarn threshold, after which the identified + transaction should be logged as a WARN level alert as well as (more importantly) an idleClose or + openClose threshold after which the transaction and the connection it applies to will be + closed. + This feature is particularly useful in environments where the owner of the broker does not + have full control over the implementation of clients, such as in a shared services + deployment. + The following section provide more details on this feature and its use. +
+
+ Purpose + This feature has been introduced to address the scenario where an open transaction on the + broker holds an open transaction on the persistent store. This can have undesirable consequences + if the store does not time out or close long-running transactions, such as with BDB. This can can result in a rapid increase in + disk usage size, bounded only by available space, due to growth of the transaction log. +
+
+ Scope + Note that only MessageProducer clients will be affected by a transaction timeout, since store + transaction lifespan on a consumer only spans the execution of the call to Session#commit() and + there is no scope for a long-lived transaction to arise. + It is also important to note that the transaction timeout mechanism is purely a JMS + transaction timeout, and unrelated to any other timeouts in the Qpid client library and will have + no impact on any RDBMS your application may utilise. +
+
+ Effect + Full details of configuration options are provided in the sections that follow. This section + gives a brief overview of what the Transaction Timeout feature can do. +
+ Broker Logging and Connection Close + When the openWarn or idleWarn specified threshold is exceeded, the broker will log a WARN + level alert with details of the connection and channel on which the threshold has been exceeded, + along with the age of the transaction. + When the openClose or idleClose specified threshold value is exceeded, the broker will + throw an exception back to the client connection via the ExceptionListener, log the + action and then close the connection. + The example broker log output shown below is where the idleWarn threshold specified is + lower than the idleClose threshold and the broker therefore logs the idle transaction 3 times + before the close threshold is triggered and the connection closed out. + + + The second example broker log output shown below illustrates the same mechanism operating + on an open transaction. + + +
+
+ Client Side Effect + After a Close threshold has been exceeded, the trigger client will receive this exception + on its exception + listener, prior to being disconnected: + org.apache.qpid.AMQConnectionClosedException: Error: Idle transaction timed out + [error code 506: resource error] + Any later attempt to use the connection will result in this exception being thrown: + + + Thus clients must be able to handle this case successfully, reconnecting where required and + registering an exception listener on all connections. This is critical, and must be communicated + to client applications by any broker owner switching on transaction timeouts. +
+ +
+
+ Configuration +
+ Configuration + Transaction timeouts are configurable separately on each defined virtual host, using the + virtualhosts.xml file. + We would recommend that only warnings are configured at first, which should allow broker + administrators to obtain an idea of the distribution of transaction lengths on their systems, + and configure production settings appropriately for both warning and closure. Ideally + establishing thresholds should be achieved in a representative UAT environment, with clients and + broker running, prior to any production deployment. + It is impossible to give suggested values, due to the large variation in usage depending on + the applications using a broker. However, clearly transactions should not span the expected + lifetime of any client application as this would indicate a hung client. + When configuring warning and closure timeouts, it should be noted that these only apply to + message producers that are connected to the broker, but that a timeout will cause the connection + to be closed - this disconnecting all producers and consumers created on that connection. + This should not be an issue for environments using Mule or Spring, where connection + factories can be configured appropriately to manage a single MessageProducer object per JMS + Session and Connection. Clients that use the JMS API directly should be aware that sessions + managing both consumers and producers, or multiple producers, will be affected by a single + producer hanging or leaving a transaction idle or open, and closed, and must take appropriate + action to handle that scenario. +
+
+ Virtualhosts.xml + The JMS transaction timeouts are configured on each virtual host defined in the XML + configuration files. + The default values for each of the parameters is 0, indicating that the particular check + is disabled. + Any or all of the parameters can be set, using the desired value in milliseconds, and will + be checked each time the housekeeping process runs, usually set to run every 30 seconds in + standard configuration. The meaning of each property is as follows: + + + + openWarn - the time a transaction can be open for (with activity occurring on it) after + which a warning alert will be issued. + + + openClose - the time a transaction can be open for before the connection it is on is + closed. + + + idleWarn - the time a transaction can be idle for (with no activity occurring on it) + after which a warning alert will be issued. + + + idleClose - the time a transaction can be idle for before the connection it is on is + closed. + + + + The virtualhosts configuration is shown below, and must occur inside the + //virtualhosts/virtualhost/name/ elements: + +Configuring producer transaction timeout + + 10000 + 20000 + 5000 + 15000 + + ]]> + +
+
+
diff --git a/doc/book/src/java-broker/Java-Broker-Runtime.xml b/doc/book/src/java-broker/Java-Broker-Runtime.xml new file mode 100644 index 0000000000..2af775d2fc --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Runtime.xml @@ -0,0 +1,30 @@ + + + + + Runtime + + + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Security-ACLs.xml b/doc/book/src/java-broker/Java-Broker-Security-ACLs.xml new file mode 100644 index 0000000000..21e1052183 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security-ACLs.xml @@ -0,0 +1,536 @@ + + + + +
+ Access Control Lists + + In Qpid, Access Control Lists (ACLs) specify which actions can be performed by each authenticated user. + To enable, the <acl/> element is used within the <security/> element of the configuration XML. + In the Java Broker, the ACL may be imposed broker wide or applied to individual virtual + hosts. The <acl/> configuration references a text file containing the ACL rules. + By convention, this file should have a .acl extension. + + + +
+ + Enabling ACLs + + + + To apply an ACL broker-wide, add the following to the config.xml (assuming that conf has been set to a suitable + location such as ${QPID_HOME}/etc): + + + + <broker> + ... + <security> + ... + <acl>${conf}/broker.acl</acl> + </security> + </broker> + + + + + + + To apply an ACL on a single virtualhost named test, add the following to the config.xml: + + + + <virtualhost> + ... + <name>test</name> + <test> + ... + <security> + <acl>${conf}/vhost_test.acl</acl> + </security> + </test> + </virtualhost> + +
+ +
+ + Writing .acl files + + + + The ACL file consists of a series of rules associating behaviour for a user or group. Use of groups can serve to make the ACL file more concise. See Configuring Group Providers for more information on defining groups. + + + Each ACL rule grants or denies a particular action on an object to a user/group. The rule may be augmented with one or more properties, restricting + the rule's applicability. + + + ACL ALLOW alice CREATE QUEUE # Grants alice permission to create all queues. + ACL DENY bob CREATE QUEUE name="myqueue" # Denies bob permission to create a queue called "myqueue" + + + The ACL is considered in strict line order with the first matching rule taking precedence over all those that follow. In the following + example, if the user bob tries to create an exchange "myexch", the operation will be allowed by the first rule. The second rule will + never be considered. + + + ACL ALLOW bob ALL EXCHANGE + ACL DENY bob CREATE EXCHANGE name="myexch" # Dead rule + + + If the desire is to allow bob to create all exchanges except "myexch", order of the rules must be reversed: + + + ACL DENY bob CREATE EXCHANGE name="myexch" + ACL ALLOW bob ALL EXCHANGE + + + All ACL files end with an implict rule denying all operations to all users. It is as if each file ends with + ACL DENY ALL ALL + If instead you wish to allow all operations other than those controlled by earlier rules, + add ACL ALLOW ALL ALL to the bottom of the ACL file. + + + When writing a new ACL, a good approach is to begin with an .acl file containing only ACL DENY-LOG ALL ALL + which will cause the Broker to deny all operations with details of the denial logged to the Qpid log file. Build up the ACL rule by rule, + gradually working through the use-cases of your system. Once the ACL is complete, consider switching the DENY-LOG actions to DENY + to improve performamce and reduce log noise. + + + ACL rules are very powerful: it is possible to write very granular rules specifying many broker objects and their + properties. Most projects probably won't need this degree of flexibility. A reasonable approach is to choose to apply permissions + at a certain level of abstraction (e.g. QUEUE) and apply them consistently across the whole system. + +
+ +
+ + Syntax + + + + ACL rules follow this syntax: + + + ACL {permission} {<group-name>|<user-name>>|ALL} {action|ALL} [object|ALL] [property="<property-value>"] + + + + Comments may be introduced with the hash (#) character and are ignored. Long lines can be broken with the slash (\) character. + + + # A comment + ACL ALLOW admin CREATE ALL # Also a comment + ACL DENY guest \ + ALL ALL # A broken line + +
+ + List of ACL permission + + + + ALLOW + Allow the action + + + ALLOW-LOG + Allow the action and log the action in the log + + + DENY + Deny the action + + + DENY-LOG + Deny the action and log the action in the log + + + +
+ + List of ACL actions + + + + CONSUME + Applied when subscriptions are created + + + PUBLISH + Applied on a per message basis on publish message transfers + + + CREATE + Applied when an object is created, such as bindings, queues, exchanges + + + ACCESS + Applied when an object is read or accessed + + + BIND + Applied when queues are bound to exchanges + + + UNBIND + Applied when queues are unbound from exchanges + + + DELETE + Applied when objects are deleted + + + PURGE + Applied when purge the contents of a queue + + + UPDATE + Applied when an object is updated + + + +
+ + List of ACL objects + + + + VIRTUALHOST + A virtualhost (Java Broker only) + + + MANAGEMENT + Management - for web and JMX (Java Broker only) + + + QUEUE + A queue + + + EXCHANGE + An exchange + + + USER + A user (Java Broker only) + + + GROUP + A group (Java Broker only) + + + METHOD + Management or agent or broker method (Java Broker only) + + + LINK + A federation or inter-broker link (not currently used in Java Broker) + + + BROKER + The broker (not currently used in Java Broker) + + + +
+ + List of ACL properties + + + + name + String. Object name, such as a queue name, exchange name or JMX method name. + + + durable + Boolean. Indicates the object is durable + + + routingkey + String. Specifies routing key + + + passive + Boolean. Indicates the presence of a passive flag + + + autodelete + Boolean. Indicates whether or not the object gets deleted when the connection is closed + + + exclusive + Boolean. Indicates the presence of an exclusive flag + + + temporary + Boolean. Indicates the presence of an temporary flag + + + type + String. Type of object, such as topic, fanout, or xml + + + alternate + String. Name of the alternate exchange + + + queuename + String. Name of the queue (used only when the object is something other than queue + + + component + String. JMX component name (Java Broker only) + + + schemapackage + String. QMF schema package name (Not used in Java Broker) + + + schemaclass + String. QMF schema class name (Not used in Java Broker) + + + from_network + + + Comma-separated strings representing IPv4 address ranges. + + + Intended for use in ACCESS VIRTUALHOST rules to apply firewall-like restrictions. + + + The rule matches if any of the address ranges match the IPv4 address of the messaging client. + The address ranges are specified using either Classless Inter-Domain Routing notation + (e.g. 192.168.1.0/24; see RFC 4632) + or wildcards (e.g. 192.169.1.*). + + + Java Broker only. + + + + + from_hostname + + + Comma-separated strings representing hostnames, specified using Perl-style regular + expressions, e.g. .*\.example\.company\.com + + + Intended for use in ACCESS VIRTUALHOST rules to apply firewall-like restrictions. + + + The rule matches if any of the patterns match the hostname of the messaging client. + + + To look up the client's hostname, Qpid uses Java's DNS support, which internally caches its results. + + + You can modify the time-to-live of cached results using the *.ttl properties described on the + Java Networking + Properties page. + + + For example, you can either set system property sun.net.inetaddr.ttl from the command line + (e.g. export QPID_OPTS="-Dsun.net.inetaddr.ttl=0") or networkaddress.cache.ttl in + $JAVA_HOME/lib/security/java.security. The latter is preferred because it is JVM + vendor-independent. + + + Java Broker only. + + + + + +
+ + List of ACL rules + + + + UserManagement + User maintainance; create/delete/view users, change passwords etc + permissionable at broker level only + + + ConfigurationManagement + Dynammically reload configuration from disk. + permissionable at broker level only + + + LoggingManagement + Dynammically control Qpid logging level + permissionable at broker level only + + + ServerInformation + Read-only information regarding the Qpid: version number etc + permissionable at broker level only + + + VirtualHost.Queue + Queue maintainance; copy/move/purge/view etc + + + VirtualHost.Exchange + Exchange maintenance; bind/unbind queues to exchanges + + + VirtualHost.VirtualHost + Virtual host maintainace; create/delete exchanges, queues etc + + + +
+
+ + Worked Examples + + + Here are some example ACLs illustrating common use cases. + In addition, note that the Java broker provides a complete example ACL file, located at etc/broker_example.acl. + +
+ + Worked example 1 - Management rights + + + Suppose you wish to permission two users: a user 'operator' must be able to perform all Management operations, and + a user 'readonly' must be enable to perform only read-only functions. Neither 'operator' nor 'readonly' + should be allowed to connect clients for messaging. + + +# Deny (loggged) operator/readonly permission to connect messaging clients. +ACL DENY-LOG operator ACCESS VIRTUALHOST +ACL DENY-LOG readonly ACCESS VIRTUALHOST +# Give operator permission to perfom all other actions +ACL ALLOW operator ALL ALL +# Give readonly permission to execute only read-only actions +ACL ALLOW readonly ACCESS ALL +... +... rules for other users +... +# Explicitly deny all (log) to eveyone +ACL DENY-LOG ALL ALL + +
+
+ + Worked example 2 - User maintainer group + + + Suppose you wish to restrict User Management operations to users belonging to a + group 'usermaint'. No other user + is allowed to perform user maintainence This example illustrates the permissioning of an individual component. + + +# Give usermaint access to management and permission to execute all JMX Methods on the +# UserManagement MBean and perform all actions for USER objects +ACL ALLOW usermaint ACCESS MANAGEMENT +ACL ALLOW usermaint ALL METHOD component="UserManagement" +ACL ALLOW usermaint ALL USER +ACL DENY ALL ALL METHOD component="UserManagement" +ACL DENY ALL ALL USER +... +... rules for other users +... +ACL DENY-LOG ALL ALL + +
+
+ + Worked example 3 - Request/Response messaging + + + Suppose you wish to permission a system using a request/response paradigm. Two users: 'client' publishes requests; + 'server' consumes the requests and generates a response. This example illustrates the permissioning of AMQP exchanges + and queues. + + +# Allow client and server to connect to the virtual host. +ACL ALLOW client ACCESS VIRTUALHOST +ACL ALLOW server ACCESS VIRTUALHOST + +# Client side +# Allow the 'client' user to publish requests to the request queue. As is the norm for the request/response paradigm, the client +# is required to create a temporary queue on which the server will respond. Consequently, there are rules to allow the creation +# of the temporary queues and consumption of messages from it. +ACL ALLOW client CREATE QUEUE temporary="true" +ACL ALLOW client CONSUME QUEUE temporary="true" +ACL ALLOW client DELETE QUEUE temporary="true" +ACL ALLOW client BIND EXCHANGE name="amq.direct" temporary="true" +ACL ALLOW client UNBIND EXCHANGE name="amq.direct" temporary="true" +ACL ALLOW client PUBLISH EXCHANGE name="amq.direct" routingKey="example.RequestQueue" + +# Server side +# Allow the 'server' user to consume from the request queue and publish a response to the temporary response queue created by +# client. We also allow the server to create the request queue. +ACL ALLOW server CREATE QUEUE name="example.RequestQueue" +ACL ALLOW server CONSUME QUEUE name="example.RequestQueue" +ACL ALLOW server BIND EXCHANGE +ACL ALLOW server PUBLISH EXCHANGE name="amq.direct" routingKey="TempQueue*" + +ACL DENY-LOG all all + +
+
+ + Worked example 4 - firewall-like access control + + + This example illustrates how to set up an ACL that restricts the IP addresses and hostnames + of messaging clients that can access a virtual host. + + +################ +# Hostname rules +################ + +# Allow messaging clients from company1.com and company1.co.uk to connect +ACL ALLOW all ACCESS VIRTUALHOST from_hostname=".*\.company1\.com,.*\.company1\.co\.uk" + +# Deny messaging clients from hosts within the dev subdomain +ACL DENY-LOG all ACCESS VIRTUALHOST from_hostname=".*\.dev\.company1\.com" + +################## +# IP address rules +################## + +# Deny access to all users in the IP ranges 192.168.1.0-192.168.1.255 and 192.168.2.0-192.168.2.255, +# using the notation specified in RFC 4632, "Classless Inter-domain Routing (CIDR)" +ACL DENY-LOG messaging-users ACCESS VIRTUALHOST \ + from_network="192.168.1.0/24,192.168.2.0/24" + +# Deny access to all users in the IP ranges 192.169.1.0-192.169.1.255 and 192.169.2.0-192.169.2.255, +# using wildcard notation. +ACL DENY-LOG messaging-users ACCESS VIRTUALHOST \ + from_network="192.169.1.*,192.169.2.*" + +ACL DENY-LOG all all + +
+
+
diff --git a/doc/book/src/java-broker/Java-Broker-Security-Authentication-Providers.xml b/doc/book/src/java-broker/Java-Broker-Security-Authentication-Providers.xml new file mode 100644 index 0000000000..0974441ae5 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security-Authentication-Providers.xml @@ -0,0 +1,320 @@ + + + + +
+ Authentication Providers + + In order to successfully establish a connection to the Java Broker, the connection must be + authenticated. The Java Broker supports a number of different authentication schemes, each + with its own "authentication manager". Each of these are outlined below, along with details + of using more than one at a time. + + +
+ Password File + + TODO + + +
+ +
+ LDAP + + + LDAP authentication can be configured using the <simple-ldap-auth-manager> element + within the <security> section. An example of how to configure this is shown below. + Please note this example also configures an unused <pd-auth-manager> to use an empty + password file, this is a workaround for an issue relating to registration of security providers. + + + + NOTE: When using LDAP authentication, you must also use SSL on the brokers AMQP messaging and + JMX/HTTP management ports in order to protect passwords during transmission to the broker. + + + Configuring LDAP authentication + + SimpleLDAPAuthenticationManager + + ldaps://example.com:636/ + dc=example\,dc=com + (uid={0}) + + + + + + org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase + + + passwordFile + ${conf}/emptyPasswdFile + + + + + ... +]]> + + + + The authentication manager first connects to the ldap server anonymously and searches for the + ldap entity which is identified by the username provided over SASL. Essentially the + authentication manager calls + DirContext.search(Name name, String filterExpr, Object[] filterArgs, SearchControls cons) + with the values of search-context and search-filter as the first two arguments, and the username + as the only element in the array which is the third argument. + + + + If the search returns a name from the LDAP server, the AuthenticationManager then attempts to + login to the ldap server with the given name and the password. + + + + If the URL to open for authentication is different to that for the search, then the + authentication url can be overridden using <provider-auth-url> in addition to providing a + <provider-url>. Note that the URL used for authentication should use ldaps:// since + passwords will be being sent over it. + + + + By default com.sun.jndi.ldap.LdapCtxFactory is used to create the context, however this can be + overridden by specifying <ldap-context-factory> in the configuration. + +
+ +
+ Kerberos + + + Kereberos Authentication is configured using the <kerberos-auth-manager> element within + the <security> section. When referencing from the default-auth-manager or port-mapping + sections, its name is KerberosAuthenticationManager. + + + + Since Kerberos support only works where SASL authentication is available (e.g. not for JMX + authentication) you may wish to also include an alternative Authentication Manager + configuration, and use this for other ports: + + + + Configuring Kerberos authentication + + + + org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase + + + passwordFile + ${conf}/passwd + + + + + + PrincipalDatabaseAuthenticationManager + + + 5672 + KerberosAuthenticationManager + + + ... +]]> + + + + Configuration of kerberos is done through system properties (there doesn't seem to be a way + around this unfortunately). + + + + export QPID_OPTS=-Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=qpid.conf + ${QPID_HOME}/bin/qpid-server + + + Where qpid.conf would look something like this: + + /"; +};]]> + + + Where realm, kdc, keyTab and principal should obviously be set correctly for the environment + where you are running (see the existing documentation for the C++ broker about creating a keytab + file). + + + + Note: You may need to install the "Java Cryptography Extension (JCE) Unlimited Strength + Jurisdiction Policy Files" appropriate for your JDK in order to get Kerberos support working. + +
+ +
+ External (SSL Client Certificates) + + + When requiring SSL Client Certificates be + presented the ExternalAuthenticationManager can be used, such that the user is authenticated based on + trust of their certificate alone, and the X500Principal from the SSL session is then used as the username + for the connection, instead of also requiring the user to present a valid username and password. + + + + The ExternalAuthenticationManager may be enabled by adding an empty <external-auth-manager> element to + the <security> section, as shown below. When referencing it from the default-auth-manager or port-mapping + sections, its name is ExternalAuthenticationManager. + + + + Note: The ExternalAuthenticationManager should typically only be used on the + AMQP ports, in conjunction with SSL client certificate + authentication. It is not intended for other uses such as the JMX management port and will treat any + non-sasl authentication processes on these ports as successfull with the given username. As such you should + include another Authentication Manager for use on non-AMQP ports, + as is done in the example below. Perhaps the only exception to this would be where the broker is embedded in a + container that is itself externally protecting the HTTP interface and then providing the remote users name. + + + + Configuring external authentication (SSL client auth) + + + + org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase + + + passwordFile + ${conf}/passwd + + + + + + PrincipalDatabaseAuthenticationManager + + + 5672 + ExternalAuthenticationManager + + + ... +]]> + + +
+ +
+ Anonymous + + + The AnonymousAuthenticationManager will allow users to connect with or without credentials and result + in their identification on the broker as the user ANONYMOUS. It may be enabled by adding an empty + anonymous-auth-manager element to the security configuration section, as shown below. + + + + Configuring anonymous authentication + + + + ... +]]> + + + + When referencing it from the default-auth-manager or port-mapping sections, its name is + AnonymousAuthenticationManager. + +
+ +
+ Configuring multiple Authentication Providers + + Different managers may be used on different ports. Each manager has its own configuration element, + the presence of which within the <security> section denotes the use of that authentication + provider. Where only one such manager is configured, it will be used on all ports (including JMX + and HTTP). Where more than one authentication manager is configured the configuration must define + which is the "default", and (if required) the mapping of non-default authentication managers to + other ports. + + + The following configuration sets up three authentication managers, using a password file as the + default (e.g. for the JMX and HTTP ports), Kerberos on port 5672 (the regular AMQP port) and Anonymous + on port 5673 (e.g a second AMQP port the broker could have been configured with). + + + + Configuring multiple (per-port) authentication schemes + + + + org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase + + + passwordFile + ${conf}/passwd + + + + + + sib + + + PrincipalDatabaseAuthenticationManager + + + 5672 + KerberosAuthenticationManager + + + 5673 + AnonymousAuthenticationManager + + + ... +]]> + +
+ +
+ diff --git a/doc/book/src/java-broker/Java-Broker-Security-Group-Providers.xml b/doc/book/src/java-broker/Java-Broker-Security-Group-Providers.xml new file mode 100644 index 0000000000..eaecd85770 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security-Group-Providers.xml @@ -0,0 +1,73 @@ + + + + +
+ Configuring Group Providers + + The Java broker utilises GroupProviders to allow assigning users to groups for use in ACLs. Following authentication by a given Authentication Provider, the configured Group Providers are consulted to allowing assignment of GroupPrincipals for a given authenticated user. + + + +
+ FileGroupManager + + The FileGroupManager allows specifying group membership in a flat file on disk, and is also exposed for inspection and update through the brokers HTTP management interface. + + + To enable the FileGroupManager, add the following configuration to the config.xml, adjusting the groupFile attribute value to match your desired groups file location. + + + + + + + groupFile + ${conf}/groups + + + + ]]> + ... + + +
+ File Format + + The groups file has the following format: + + + # <GroupName>.users = <comma deliminated user list> + # For example: + + administrators.users = admin,manager + + + Only users can be added to a group currently, not other groups. Usernames can't contain commas. + + Lines starting with a '#' are treated as comments when opening the file, but these are not preserved when the broker updates the file due to changes made through the management interface. + +
+
+
diff --git a/doc/book/src/java-broker/Java-Broker-Security-SSL.xml b/doc/book/src/java-broker/Java-Broker-Security-SSL.xml new file mode 100644 index 0000000000..e415065a84 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security-SSL.xml @@ -0,0 +1,119 @@ + + +%entities; +]> + + +
+ SSL + + + This section will show how to use SSL to enable secure + connections between an AMQP message client and the broker. + +
+ Keystore Configuration + + The broker configuration file (config.xml) needs to be updated to include the required SSL keystore + configuration, an example of which can be found below. + + + + Configuring an SSL Keystore + + ... + + true + 5671 + false + /path/to/keystore.ks + keystorepass + alias + + ... +]]> + + + + The certAlias element is an optional way of specifying which certificate the broker should use + if the keystore contains multiple entries. + + + + The sslOnly element controls whether the broker will only bind + the configured SSL port(s) or will also bind the non-SSL port(s). Setting sslOnly to true will + disable the non-SSL ports. + + + + + The password of the certificate used by the Broker must + match the password of the keystore itself. This is a restriction of the Qpid Broker + implementation. If using the keytool utility, + note that this means the argument to the option must match + the option. + + +
+ +
+ Truststore / Client Certificate Authentication + + The SSL trustore and related Client Certificate Authentication behaviour can be configured with + additional configuration as shown in the example below, in which the broker requires client + certificate authentication. + + + + Configuring an SSL Truststore and client auth + + ... + + ... + /path/to/truststore.ks + truststorepass + true + false + ... + + ... +]]> + + + + The needClientAuth and wantClientAuth elements allow control of whether the client must present an + SSL certificate. Only one of these elements is needed but both may be used at the same time. + A socket's client authentication setting is one of three states: required (needClientAuth = true), + requested (wantClientAuth = true), or none desired (both false, the default). If both elements are + set to true, needClientAuth takes precedence. + + + + When using Client Certificate Authentication it may be desirable to use the External Authentication + Manager, for details see + + +
+
diff --git a/doc/book/src/java-broker/Java-Broker-Security-Users-And-Groups.xml b/doc/book/src/java-broker/Java-Broker-Security-Users-And-Groups.xml new file mode 100644 index 0000000000..2125f3a3df --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security-Users-And-Groups.xml @@ -0,0 +1,26 @@ + + + +
+Users And Groups + +
diff --git a/doc/book/src/java-broker/Java-Broker-Security.xml b/doc/book/src/java-broker/Java-Broker-Security.xml new file mode 100644 index 0000000000..3db672100e --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Security.xml @@ -0,0 +1,30 @@ + + + + + Security + + + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Stores-BDB-Store.xml b/doc/book/src/java-broker/Java-Broker-Stores-BDB-Store.xml new file mode 100644 index 0000000000..c16d9aa227 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores-BDB-Store.xml @@ -0,0 +1,94 @@ + + +%entities; +]> + + +
+ BDB Store + + The Java broker has an optional message store implementation backed by Oracle BDB JE. + This section will detail where to download the optional dependency from, how to add it to the broker installation, + and provide an example configuration for using the BDBMessageStore. + + +
+ Oracle BDB JE download + + The BDB based message store is optional due to its dependency on Oracle BDB JE, which is distributed under the Sleepycat + licence. As a result of this, the dependency cant be distributed by the Apache Qpid project as part of the broker release package. + + + If you wish to use the BDBMessageStore, then you must download the Oracle BDB JE &oracleBdbProductVersion; release + from the Oracle website. + + + The download has a name in the form je-&oracleBdbProductVersion;.tar.gz. It is recommended that you + confirm the integrity of the download by verifying the MD5. + +
+ +
+ Oracle BDB JE jar installation + + If you wish to use the BDBMessageStore, copy the je-&oracleBdbProductVersion;.jar from within the release + downloaded above into the 'opt' sub-directory + of the brokers 'lib' directory. + + + Unix: +cp je-&oracleBdbProductVersion;.jar qpid-broker-&qpidCurrentRelease;/lib/opt + + Windows: +copy je-&oracleBdbProductVersion;.jar qpid-broker-&qpidCurrentRelease;\lib\opt +
+ + + +
+ Configuration + + In order to use the BDBMessageStore, you must configure it for each VirtualHost desired by updating the store element + to specify the associated store class and provide a directory location for the data to be written, as shown below. + + + + Configuring a VirtualHost to use the BDBMessageStore + + + vhostname + + + org.apache.qpid.server.store.berkeleydb.BDBMessageStore + ${QPID_WORK}/bdbstore/vhostname + + ... + + + +]]> + +
+ +
diff --git a/doc/book/src/java-broker/Java-Broker-Stores-Derby-Store.xml b/doc/book/src/java-broker/Java-Broker-Stores-Derby-Store.xml new file mode 100644 index 0000000000..042b2324de --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores-Derby-Store.xml @@ -0,0 +1,56 @@ + + + +
+Derby Store + + The Java broker has a message store implementation backed by Apache Derby. + This section will detail configuration for using the DerbyMessageStore. + + +
+ Configuration + + In order to use the DerbyMessageStore, you must configure it for each VirtualHost desired by updating the store element + to specify the associated store class and provide a directory location for the data to be written, as shown below. + + + + Configuring a VirtualHost to use the DerbyMessageStore + + + vhostname + + + org.apache.qpid.server.store.DerbyMessageStore + ${QPID_WORK}/derbystore/vhostname + + ... + + + +]]> + +
+ +
diff --git a/doc/book/src/java-broker/Java-Broker-Stores-HA-BDB-Store.xml b/doc/book/src/java-broker/Java-Broker-Stores-HA-BDB-Store.xml new file mode 100644 index 0000000000..e8a13c52dc --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores-HA-BDB-Store.xml @@ -0,0 +1,62 @@ + + + +
+ High Availability BDB Store + + The Java broker has an optional High Availability message store implementation backed by Oracle BDB JE HA. + This section references information on where to download the optional dependency from, how to add it to the broker + installation, and how to configure the BDBHAMessageStore. + + + For more detailed information about use of this store, see . + + +
+ Oracle BDB JE download + + For details, see . + +
+ +
+ Oracle BDB JE jar installation + + For details, see . + +
+ +
+ Configuration + + In order to use the BDBHAMessageStore, you must configure it for each VirtualHost desired by updating the store element + to specify the associated store class, provide a directory location for the data to be written, and configure the + replication group and policies used by BDB JA HA. + + + A general configuration example is shown here, however it + is strongly recommended you examine the wider context of for a fuller + discussion of the various configuration options and how to use them. + +
+ +
diff --git a/doc/book/src/java-broker/Java-Broker-Stores-Memory-Store.xml b/doc/book/src/java-broker/Java-Broker-Stores-Memory-Store.xml new file mode 100644 index 0000000000..b8694f3315 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores-Memory-Store.xml @@ -0,0 +1,61 @@ + + + +
+ Memory Store + + The Java broker has an in-memory message store implementation. + This section will detail configuration for using the MemoryMessageStore. + + + Note: when using this store, the broker will store both persistent and non-persistent messages + in memory, which is to say that neither will be available following a broker restart, and the + ability to store new messages will be entirely constrained by the JVM heap size. + + +
+ Configuration + + In order to use the MemoryMessageStore, you must configure it for each VirtualHost desired by updating the store element + to specify the associated store class, as shown below. + + + + Configuring a VirtualHost to use the MemoryMessageStore + + + vhostname + + + org.apache.qpid.server.store.MemoryMessageStore + ... + + + +]]> + +
+ + +
diff --git a/doc/book/src/java-broker/Java-Broker-Stores-SQL-Store.xml b/doc/book/src/java-broker/Java-Broker-Stores-SQL-Store.xml new file mode 100644 index 0000000000..b6776c81e6 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores-SQL-Store.xml @@ -0,0 +1,26 @@ + + + +
+SQL Store + +
diff --git a/doc/book/src/java-broker/Java-Broker-Stores.xml b/doc/book/src/java-broker/Java-Broker-Stores.xml new file mode 100644 index 0000000000..aee3cdebdb --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Stores.xml @@ -0,0 +1,30 @@ + + + + + Stores + + + + + + diff --git a/doc/book/src/java-broker/Java-Broker-Virtual-Hosts.xml b/doc/book/src/java-broker/Java-Broker-Virtual-Hosts.xml new file mode 100644 index 0000000000..fc1a8b1dc5 --- /dev/null +++ b/doc/book/src/java-broker/Java-Broker-Virtual-Hosts.xml @@ -0,0 +1,25 @@ + + + + + Virtual Hosts + diff --git a/doc/book/src/java-broker/Java-Environment-Variables.xml b/doc/book/src/java-broker/Java-Environment-Variables.xml deleted file mode 100644 index 12703190f2..0000000000 --- a/doc/book/src/java-broker/Java-Environment-Variables.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - -
- - Java Environment Variables - -
- - Setting - Qpid Environment Variables - - -
- - Qpid - Deployment Path Variables - - - There are two main Qpid environment variables which are required - to be set for Qpid deployments, QPID_HOME and QPID_WORK. - - - QPID_HOME - This variable is used to tell the Qpid broker where - it's installed home is, which is in turn used to find dependency - JARs which Qpid uses. - - - QPID_WORK - This variable is used by Qpid when creating all - 'writeable' directories that it uses. This includes the log - directory and the storage location for any BDB instances in use - by your deployment (if you're using persistence with BDB). If you - do not set this variable, then the broker will default (in the - qpid-server script) to use the current user's homedir as the root - directory for creating the writeable locations that it uses. - - - -
- -
- - Setting - Max Memory for the broker - - - If you simply start the Qpid broker, it will default to use a - -Xmx setting of 1024M for the broker JVM. However, we would - recommend that you make the maximum -Xmx heap size available, if - possible, of 3Gb (for 32-bit platforms). - - - You can control the memory setting for your broker by setting the - QPID_JAVA_MEM variable before starting the broker e.g. -Xmx3668m - . Enclose your value within quotes if you also specify a -Xms - value. The value in use is echo'd by the qpid-server script on - startup. - - -
- - -
- -
diff --git a/doc/book/src/java-broker/Management-Console-Security.xml b/doc/book/src/java-broker/Management-Console-Security.xml deleted file mode 100644 index 31f63c70da..0000000000 --- a/doc/book/src/java-broker/Management-Console-Security.xml +++ /dev/null @@ -1,251 +0,0 @@ - - - -
- Management Console Security -
- Management - Console Security - - - - - - - - - - - - -
- SSL - encrypted RMI (0.5 and above) - - - Current versions of the broker make use of SSL encryption to - secure their RMI based JMX ConnectorServer for security purposes. - This ships enabled by default, although the test SSL keystore - used during development is not provided for security reasons - (using this would provide no security as anyone could have access - to it). -
- Broker - Configuration - - - - The broker configuration must be updated before the broker will - start. This can be done either by disabling the SSL support, - utilizing a purchased SSL certificate to create a keystore of - your own, or generating a self-signed keystore. - - The broker must be configured with a keystore containing the - private and public keys associated with its SSL certificate. This - is accomplished by setting the Java environment properties - javax.net.ssl.keyStore and - javax.net.ssl.keyStorePassword respectively with the - location and password of an appropriate SSL keystore. Entries for - these properties exist in the brokers main configuration file - alongside the other management settings (see below), although the - command line options will still work and take precedence over the - configuration file. - - -<management> - <ssl> - <enabled>true</enabled> - <!-- Update below path to your keystore location, eg ${conf}/qpid.keystore --> - <keyStorePath>${conf}/qpid.keystore</keyStorePath> - <keyStorePassword>password</keyStorePassword> - </ssl> -</management> - -
- -
- JMX - Management Console Configuration - - - - If the broker makes use of an SSL certificate signed by a known - signing CA (Certification Authority), the management console - needs no extra configuration, and will make use of Java's - built-in CA - truststore for certificate verification (you may however have to - update the system-wide default truststore if your CA is not - already present in it). - - If however you wish to use a self-signed SSL certificate, then - the management console must be provided with an SSL truststore - containing a record for the SSL certificate so that it is able to - validate it when presented by the broker. This is performed by - setting the javax.net.ssl.trustStore and - javax.net.ssl.trustStorePassword environment variables - when starting the console. This can be done at the command line, - or alternatively an example configuration has been made within - the console's qpidmc.ini launcher configuration file that may - pre-configured in advance for repeated usage. See the for more - information on this configuration process. - -
- -
- JConsole - Configuration - - - - As with the JMX Management Console above, if the broker is using - a self-signed SSL certificate then in order to connect remotely - using JConsole, an appropriate trust store must be provided at - startup. See for further details on configuration. - -
- -
- Additional - Information - - - - More information on Java's handling of SSL certificate - verification and customizing the keystores can be found in the - http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores. - -
-
- - - -
- JMXMP - (M4 and previous) - - - - In previous releases of Qpid (M4 and below) the broker, can make - use of Sun's Java Management Extensions Messaging Protocol - (JMXMP) to provide encryption of the JMX connection, offering - increased security over the default unencrypted RMI based JMX - connection. -
- Download and - Install - - - - This is possible by adding the jmxremote_optional.jar as provided - by Sun. This jar is covered by the Sun Binary Code License and is - not compatible with the Apache License which is why this - component is not bundled with Qpid. - - Download the JMX Remote API 1.0.1_04 Reference Implementation - from . The included - 'jmxremote-1_0_1-bin\lib\jmxremote_optional.jar' file must be - added to the broker classpath: - - First set your classpath to something like this: - - -CLASSPATH=jmxremote_optional.jar - - - Then, run qpid-server passing the following additional flag: - - -qpid-server -run:external-classpath=first - - - Following this the configuration option can be updated to enabled - use of the JMXMP based JMXConnectorServer. - -
- -
- Broker - Configuration - - - - To enabled this security option change the - security-enabled value in your broker configuration - file. - - - <management> - <security-enabled>true</security-enabled> - </management> - - - You may also (for M2 and earlier) need to set the following - system properties using the environment variable QPID_OPTS: - - QPID_OPTS="-Dcom.sun.management.jmxremote - -Dcom.sun.management.jmxremote.port=8999 - -Dcom.sun.management.jmxremote.authenticate=false - -Dcom.sun.management.jmxremote.ssl=false" - -
- -
- JMX - Management Console Configuration - - - - If you wish to connect to a broker configured to use JMXMP then - the console also requires provision of the Optional sections of - the JMX Remote API that are not included within the JavaSE - platform. - - In order to make it available to the console, place the - 'jmxremote_optional.jar' (rename the file if any additional - information is present in the file name) jar file within the - 'plugins/jmxremote.sasl_1.0.1/' folder of the console release (on - Mac OS X you will need to select 'Show package contents' from the - context menu whilst selecting the management console bundle in - order to reveal the inner file tree). - - Following the the console will automatically load the JMX Remote - Optional classes and attempt the JMXMP connection when connecting - to a JMXMP enabled broker. - -
-
- -
- User - Accounts & Access Rights - - - - In order to access the management operations via JMX, users must - have an account and have been assigned appropriate access rights. - See - -
-
- - -
diff --git a/doc/book/src/java-broker/OtherQueueTypes.xml b/doc/book/src/java-broker/OtherQueueTypes.xml deleted file mode 100644 index d42e4e62cb..0000000000 --- a/doc/book/src/java-broker/OtherQueueTypes.xml +++ /dev/null @@ -1,274 +0,0 @@ - - -]> - - -
- Other Queue Types - -
- Introduction - In addition to the standard queue type where messages are delivered in the same order - that they were sent, the Java Broker supports three additional queue types which allows for - alternative delivery behaviours. These are priority-queues, sorted-queues-, and - last-value-queues (LVQs). - In the following sections, the semantics of each queue type is described, followed by a - description of how instances of these queue can be created via configuration or programmatically. - The final section discusses the importance of using a low client pre-fetch with these queued. - -
- -
- Priority Queues - In a priority queue, messages on the queue are delivered in an order determined by the - JMS priority message - header within the message. By default Qpid supports the 10 priority levels mandated - by JMS, with priority value 0 as the lowest priority and 9 as the highest. - It is possible to reduce the effective number of priorities if desired. - JMS defines the - default message priority as 4. Messages sent without a specified priority use this - default. -
-
- Sorted Queues - Sorted queues allow the message delivery order to be determined by value of an arbitrary - JMS message - property. Sort order is alpha-numeric and the property value must have a type - java.lang.String. - Messages sent to a sorted queue without the specified JMS message property will be - inserted into the 'last' position in the queue. -
-
- Last Value Queues (LVQ) - LVQs (or conflation queues) are special queues that automatically discard any message when - a newer message arrives with the same key value. The key is specified by arbitrary JMS message - property. - An example of an LVQ might be where a queue represents prices on a stock exchange: when - you first consume from the queue you get the latest quote for each stock, and then as new - prices come in you are sent only these updates. - Like other queues, LVQs can either be browsed or consumed from. When browsing an - individual subscriber does not remove the message from the queue when receiving it. This - allows for many subscriptions to browse the same LVQ (i.e. you do not need to create and bind - a separate LVQ for each subscriber who wishes to receive the contents of the LVQ). - Messages sent to an LVQ without the specified property will be delivered as normal and - will never be "replaced". -
-
- Creating a Priority, Sorted or LVQ Queue - To create a priority, sorted or LVQ queue, it can be defined in the virtualhost - configuration file, or the queue can be created programmtically from a client via AMQP (using - an extension to JMS), or using JMX. These methods are described below. - Once a queue is created you cannot change its type (without deleting it and re-creating). - Also note you cannot currently mix the natures of these queue types, for instance, you cannot - define a queue which it both an LVQ and a priority-queue. -
- Using configuration - To create a priority, sorted or LVQ queue within configuration, add the appropriate xml - to the virtualhost.xml configuration file within the queues - element. -
- Priority - To defining a priority queue, add a <priority>true</priority> element. By - default the queue will have 10 distinct priorities. - - Configuring a priority queue - - myqueue - - amq.direct - true - -]]> - - If you require fewer priorities, it is possible to specify a - priorities element (whose value is a integer value between 2 and 10 - inclusive) which will give the queue that number of distinct priorities. When messages are - sent to that queue, their effective priority will be calculated by partitioning the - priority space. If the number of effective priorities is 2, then messages with priority - 0-4 are treated the same as "lower priority" and messages with priority 5-9 are treated - equivalently as "higher priority". - - Configuring a priority queue with fewer priorities - - myqueue - - amq.direct - true - 4 - -]]> - -
-
- Sorted - To define a sorted queue, add a sortKey element. The value of the - sortKey element defines the message property to use the value of when - sorting the messages put onto the queue. - - Configuring a sorted queue - - myqueue - - amq.direct - message-property-to-sort-by - -]]> - -
-
- LVQ - To define a LVQ, add a lvq element with the value - true. Without any further configuration this will define an LVQ - which uses the JMS message property qpid.LVQ_key as the key for - replacement. - - Configuring a LVQ queue - - myqueue - - amq.direct - true - -]]> - - If you wish to define your own property then you can do so using the - lvqKey element. - - Configuring a LVQ queue with custom message property name - - myqueue - - amq.direct - true - ISIN - -]]> - -
-
-
- Using JMS or AMQP - To create a priority, sorted or LVQ queue programmatically from JMX or using a Qpid - extension to JMS, pass the appropriate queue-declare arguments. - - - - - Queue type - Argument name - Argument name - Argument Description - - - - - priority - priorities - java.lang.Integer - Specifies a priority queue with given number priorities - - - sorted - qpid.queue_sort_key - java.lang.String - Specifies sorted queue with given message property used to sort the - entries - - - lvq - qpid.last_value_queue_key - java.lang.String - Specifies lvq queue with given message property used to conflate the - entries - - - -
- The following example illustrates the creation of the a LVQ queue from a - javax.jms.Session object. Note that this utilises a Qpid specific extension to JMS and - involves casting the session object back to its Qpid base-class. - - Creation of an LVQ using the Qpid extension to JMS - arguments = new HashMap(); -arguments.put("qpid.last_value_queue_key","ISIN"); -((AMQSession) session).createQueue(queueName, autoDelete, durable, exclusive, arguments);]]> - - - The following example illustrates the creation of the sorted queue from a the JMX - interface using the ManagedBroker interface. - - Creation of a sorted queue using JMX - environment = new HashMap(); -environment.put(JMXConnector.CREDENTIALS, new String[] {"admin","password"}); -// Connect to service -JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi"); -JMXConnector jmxConnector = JMXConnectorFactory.connect(url, environment); -MBeanServerConnection mbsc = jmxConnector.getMBeanServerConnection(); -// Object name for ManagedBroker for virtualhost myvhost -ObjectName objectName = new ObjectName("org.apache.qpid:type=VirtualHost.VirtualHostManager,VirtualHost=myvhost"); -// Get the ManagedBroker object -ManagedBroker managedBroker = JMX.newMBeanProxy(mbsc, objectName, ManagedBroker.class);; - -// Create the queue passing arguments -Map arguments = new HashMap(); -arguments.put("qpid.queue_sort_key","myheader"); -managedBroker.createNewQueue("myqueue", null, true, arguments);]]> - -
-
- -
- Low pre-fetch - Qpid clients receive buffered messages in batches, sized according to the pre-fetch value. - The current default is 500. - However, if you use the default value you will probably not see - desirable behaviour when using priority, sorted or lvq queues. Once the broker has sent a - message to the client its delivery order is then fixed, regardless of the special behaviour of - the queue. - For example, if using a priority queue and a prefetch of 100, and 100 messages arrive with - priority 2, the broker will send these messages to the client. If then a new message arrives - will priority 1, the broker cannot leap frog messages of lower priority. The priority 1 will - be delivered at the front of the next batch of messages to be sent to the client. - So, you need to set the prefetch values for your client (consumer) to make this sensible. - To do this set the Java system property max_prefetch on the client - environment (using -D) before creating your consumer. - A default for all client connections can be set via a system property: - --Dmax_prefetch=1 - - The prefetch can be also be adjusted on a per connection basis by adding a - maxprefetch value to the Connection URLs - - -amqp://guest:guest@client1/development?maxprefetch='1'&brokerlist='tcp://localhost:5672' - - Setting the Qpid pre-fetch to 1 will give exact queue-type semantics as perceived by the - client however, this brings a performance cost. You could test with a slightly higher - pre-fetch to trade-off between throughput and exact semantics. -
-
diff --git a/doc/book/src/java-broker/Producer-Flow-Control.xml b/doc/book/src/java-broker/Producer-Flow-Control.xml deleted file mode 100644 index 262279510e..0000000000 --- a/doc/book/src/java-broker/Producer-Flow-Control.xml +++ /dev/null @@ -1,217 +0,0 @@ - - - -
- Producer Flow Control - -
- General Information - - The Qpid 0.6 release introduced a simplistic producer-side flow control mechanism - into the Java Messaging Broker, causing producers to be flow-controlled when they - attempt to send messages to an overfull queue. Qpid 0.18 introduced a similar - mechanism triggered by an overfull persistent message store on a virtual host. - -
-
- Server Configuration -
- Configuring a Queue to use flow control - - Flow control is enabled on a producer when it sends a message to a Queue - which is "overfull". The producer flow control will be rescinded when all - Queues on which a producer is blocking become "underfull". A Queue is defined - as overfull when the size (in bytes) of the messages on the queue exceeds the - "capacity" of the Queue. A Queue becomes "underfull" when its size becomes - less than the "flowResumeCapacity". - - - - test - - amq.direct - 10485760 - 8388608 - - - ]]> - - - The default for all queues on a virtual host can also be set - - - - - localhost - - 10485760 - 8388608 - - - - ]]> - - - Where no flowResumeCapacity is set, the flowResumeCapacity is set to be equal - to the capacity. Where no capacity is set, capacity is defaulted to 0 meaning - there is no capacity limit. - -
- Broker Log Messages - - There are four new Broker log messages that may occur if flow control through queue capacity limits is enabled. - Firstly, when a capacity limited queue becomes overfull, a log message similar to the following is produced - - -MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1003 : Overfull : Size : 1,200 bytes, Capacity : 1,000 - - Then for each channel which becomes blocked upon the overful queue a log message similar to the following is produced: - -MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1005 : Flow Control Enforced (Queue MyQueue) - - When enough messages have been consumed from the queue that it becomes underfull, then the following log is generated: - -MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1004 : Underfull : Size : 600 bytes, Resume Capacity : 800 - - And for every channel which becomes unblocked you will see a message similar to: - -MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1006 : Flow Control Removed - - Obviously the details of connection, virtual host, queue, size, capacity, etc would depend on the configuration in use. - - -
-
- -
- Disk quota-based flow control - - Since version 0.18 of Qpid Broker, flow control can be triggered when a - configured disk quota is exceeded. This is supported by the BDB and Derby message stores. - - - This functionality blocks all producers on reaching the disk overflow limit. When consumers - consume the messages, causing disk space usage to falls below the underflow limit, the - producers are unblocked and continue working as normal. - - - Two limits can be configured: - - - overfull limit - the maximum space on disk (in bytes) which can be used by store. - - - underfull limit - when the space on disk drops below this limit, producers are allowed to resume publishing. - - - An example of quota configuration for the BDB message store is provided below. - - - - org.apache.qpid.server.store.berkeleydb.BDBMessageStore - ${work}/bdbstore/test - 50000000 - 45000000 - - ]]> - - - The disk quota functionality is based on "best effort" principle. This means the broker - cannot guarantee that the disk space limit will not be exceeded. If several concurrent - transactions are started before the limit is reached, which collectively cause the limit - to be exceeded, the broker may allow all of them to be committed. - - -
- Broker Log Messages for quota flow control - - There are 2 new broker log messages that may occur if flow control through disk quota limits is enabled. - When the virtual host is blocked due to exceeding of the disk quota limit the following message - appears in the broker log - -[vh(/test)/ms(BDBMessageStore)] MST-1008 : Store overfull, flow control will be enforced - - When virtual host is unblocked after cleaning the disk space the following message appears in the broker log - -[vh(/test)/ms(BDBMessageStore)] MST-1009 : Store overfull condition cleared - - -
-
-
- - -
- Client impact and configuration - - If a producer sends to a queue which is overfull, the broker will respond by - instructing the client not to send any more messages. The impact of this is - that any future attempts to send will block until the broker rescinds the flow control order. - - - While blocking the client will periodically log the fact that it is blocked waiting on flow control. - - -WARN Message send delayed by 5s due to broker enforced flow control -WARN Message send delayed by 10s due to broker enforced flow control - - - After a set period the send will timeout and throw a JMSException to the calling code. - - - If such a JMSException is thrown, the message will not be sent to the broker, - however the underlying Session may still be active - in particular if the - Session is transactional then the current transaction will not be automatically - rolled back. Users may choose to either attempt to resend the message, or to - roll back any transactional work and close the Session. - - - Both the timeout delay and the periodicity of the warning messages can be set - using Java system properties. - - - The amount of time (in milliseconds) to wait before timing out - is controlled by the property qpid.flow_control_wait_failure. - - - The frequency at which the log message informing that the producer is flow - controlled is sent is controlled by the system property qpid.flow_control_wait_notify_period. - - - Adding the following to the command line to start the client would result in a timeout of one minute, - with warning messages every ten seconds: - - --Dqpid.flow_control_wait_failure=60000 --Dqpid.flow_control_wait_notify_period=10000 - -
- Older Clients - - The flow control feature was first added to the Java broker/client in the 0.6 release. If an older client connects to the broker then the flow control commands will be ignored by it and it will not be blocked. So to fully benefit from this feature both Client and Broker need to be at least version 0.6. - -
-
-
diff --git a/doc/book/src/java-broker/Qpid-JMX-Management-Console-FAQ.xml b/doc/book/src/java-broker/Qpid-JMX-Management-Console-FAQ.xml deleted file mode 100644 index 1806ab01b1..0000000000 --- a/doc/book/src/java-broker/Qpid-JMX-Management-Console-FAQ.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - -
- Qpid JMX Management Console FAQ - - - -
- Errors - - -
- How do I connect the management console to - my broker using security ? - - - - The page will give you the instructions that you should - use to set this up. - -
- -
- I am unable to connect Qpid JMX MC/JConsole - to a remote broker running on Linux, but connecting to localhost - on that machine works ? - - - - The RMI - based JMX ConnectorServer used by the broker requries two ports - to operate. The console connects to an RMI Registry running on - the primary (default 8999) port and retrieves the information - actually needed to connect to the JMX Server. This information - embeds the hostname of the remote machine, and if this is - incorrect or unreachable by the connecting client the connection - will fail. - - This - situation arises due to the hostname configuration on Linux and - is generally encountered when the remote machine does not have a - DNS hostname entry on the local network, causing the hostname - command to return a loopback IP instead of a fully qualified - domain name or IP address accessible by remote client machines. - It is described in further detail at: - - To - remedy this issue you can set the - java.rmi.server.hostname system property to control the - hostname/ip reported to the RMI runtime when advertising the JMX - ConnectorServer. This can also be used to dictate the address - returned on a computer with multiple network interfaces to - control reachability. To do so, add the value - -Djava.rmi.server.hostname=<desired hostname/ip> - to the QPID_OPTS environment variable before starting the - qpid-server script. - -
-
-
diff --git a/doc/book/src/java-broker/Qpid-JMX-Management-Console-User-Guide.xml b/doc/book/src/java-broker/Qpid-JMX-Management-Console-User-Guide.xml deleted file mode 100644 index 35bb5dfbe8..0000000000 --- a/doc/book/src/java-broker/Qpid-JMX-Management-Console-User-Guide.xml +++ /dev/null @@ -1,793 +0,0 @@ - - - -
- Qpid JMX Management Console User Guide -
- Qpid JMX Management Console User Guide - - - - - - The Qpid JMX Management Console is a standalone Eclipse RCP - application for managing and monitoring the Qpid Java server - utilising its JMX management interfaces. - - This guide will give an overview of configuring the console, the - features supported by it, and how to make use of the console in - managing the various JMX Management Beans (MBeans) offered by the - Qpid Java server. - -
- - -
- - Startup & Configuration - - - - - -
- Startup - - - - - The console can be started in the following way, depending on - platform: - - - Windows: by running the qpidmc.exe executable - file. - - - Linux: by running the qpidmc executable. - - - Mac OS X: by launching the Qpid Management - Console.app application bundle. - - - - -
- - -
- SSL - configuration - - - - - Newer Qpid Java servers can protect their JMX connections with - SSL, and this is enabled by default. When attempting to connect - to a server with this enabled, the console must be able to verify - the SSL certificate presented to it by the server or the - connection will fail. - - If the server makes use of an SSL certificate signed by a known - Signing CA (Certification Authority) then the console needs no - extra configuration, and will make use of Java's default - system-wide CA TrustStore for certificate verification (you may - however have to update the system-wide default CA TrustStore if - your certified is signed by a less common CA that is not already - present in it). - - If however the server is equipped with a self-signed SSL - certificate, then the management console must be provided with an - appropriate SSL TrustStore containing the public key for the SSL - certificate, so that it is able to validate it when presented by - the server. The server ships with a script to create an example - self-signed SSL certificate, and store the relevant entries in a - KeyStore and matching TrustStore. This script can serve as a - guide on how to use the Java Keytool security utility to - manipulate your own stores, and more information can be found in - the JSSE Reference Guide: - http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores. - - Supplying the necessary details to the console is performed by - setting the javax.net.ssl.trustStore and - javax.net.ssl.trustStorePassword environment variables - when starting it. This can be done at the command line, but the - preferred option is to set the configuration within the - qpidmc.ini launcher configuration file for repeated - usage. This file is equipped with a template to ease - configuration, this should be uncommented and edited to suit your - needs. It can be found in the root of the console releases for - Windows, and Linux. For Mac OS X the file is located within the - consoles .app application bundle, and to locate and edit - it you must select 'Show Package Contents' when - accessing the context menu of the application, then browse to the - Contents/MacOS sub folder to locate the file. - -
- -
- JMXMP - configuration - - - - - Older releases of the Qpid Java server can make use of the Java - Management Extensions Messaging Protocol (JMXMP) to provide - protection for their JMX connections. This occurs when the server - has its main configuration set with the management - 'security-enabled' property set to true. - - In order to connect to this configuration of server, the console - needs an additional library that is not included within the Java - SE platform and cannot be distributed with the console due to - licensing restrictions. - - You can download the JMX Remote API 1.0.1_04 Reference - Implementation from the Sun website . The included - jmxremote-1_0_1-bin/lib/jmxremote_optional.jar file must - be added to the plugins/jmxremote.sasl_1.0.1 folder of - the console release (again, in Mac OS X you will need to select - 'Show package contents' from the context menu whilst - selecting the management console bundle in order to reveal the - inner file tree). - - Following this the console will automatically load the JMX Remote - Optional classes and negotiate the SASL authentication profile - type when encountering a JMXMP enabled Qpid Java server. - -
-
-
- - Managing Server Connections - - - - - -
- Main Toolbar - - - - - The main toolbar of the console can be seen in the image below. - The left most buttons respectively allow for adding a new server - connection, reconnecting to an existing server selected in the - connection tree, disconnecting the selected server connection, - and removing the server from the connection tree. - - - - - Beside these buttons is a combo for selecting the refresh - interval; that is, how often the console requests updated - information to display for the currently open area in the main - view. Finally, the right-most button enables an immediate update. - -
- -
- Connecting - to a new server - - - - - To connect to a new server, press the Add New Server - toolbar button, or select the Qpid Manager -> Add New - Connection menu item. At this point a dialog box will be - displayed requesting the server details, namely the server - hostname, management port, and a username and password. An - example is shown below: - - - - - Once all the required details are entered, pressing Connect will - initiate a connection attempt to the server. It the attempt fails - a reason will be shown and the server will not be added to the - connection tree. If the attempt is successful the server will be - added to the connections list and the entry expanded to show the - initial administration MBeans the user has access to and any - VirtualHosts present on the server, as can be seen in the figure - below. - - - - - If the server supports a newer management API than the console in - use, once connected this initial screen will contain a message on - the right, indicating an upgraded console should be sought by the - user to ensure all management functionality supported by the - server is being utilised. - -
- -
- Reconnecting - to a server - - - - - If a server has been connected to previously, it will be saved as - an entry in the connection tree for further use. On subsequent - connections the server can simply be selected from the tree and - using the Reconnect toolbar button or Qpid Manager - -> Reconnect menu item. At this stage the console will - prompt simply for the username and password with which the user - wishes to connect, and following a successful connection the - screen will appear as shown previously above. - -
- - -
- Disconnecting - from a server - - - - - To disconnect from a server, select the connection tree node for - the server and press the Disconnect toolbar button, or - use the Qpid Manager -> Disconnect menu option. - -
- -
- Removing a - server - - - - - To remove a server from the connection list, select the - connection tree node for the server and press the Remove - toolbar button, or use the Qpid Manager -> Remove - Connection menu option. - -
-
- - -
- Navigating a connected server - - - - - Once connected to a server, the various areas available for - administration are accessed using the Qpid Connections tree at - the left side of the application. To open a particular MBean from - the tree for viewing, simply select it in the tree and it will be - opened in the main view. - - - As there may be vast numbers of Queues, Connections, and - Exchanges on the server these MBeans are not automatically added - to the tree along with the general administration MBeans. - Instead, dedicated selection areas are provided to allow users to - select which Queue/Connection/Exchange they wish to view or add - to the tree. These areas can be found by clicking on the - Connections, Exchanges, and Queues nodes in the tree under each - VirtualHost, as shown in the figure above. One or more MBeans may - be selected and added to the tree as Favourites using the button - provided. These settings are saved for future use, and each time - the console connects to the server it will check for the presence - of the MBean previously in the tree and add them if they are - still present. Queue/Connection/Exchange MBeans can be removed - from the tree by right clicking on them to expose a context menu - allowing deletion. - - - - As an alternative way to open a particular MBean for viewing, - without first adding it to the tree, you can simply double click - an entry in the table within the Queue/Connection/Exchange - selection areas to open it immediately. It is also possible to - open some MBeans like this whilst viewing certain other MBeans. - When opening an MBean in either of these ways, a Back button is - enabled in the top right corner of the main view. Using this - button will return you to the selection area or MBean you were - previously viewing. The history resets each time the tree is used - to open a new area or MBean. - -
- - -
- - ConfigurationManagement MBean - - - - - The ConfigurationManagement MBean is available on newer servers, - to users with admin level management rights. It offers the - ability to perform a live reload of the Security - sections defined in the main server configuration file (e.g. - defaults to: etc/config.xml). This is mainly to allow - updating the server Firewall configuration to new settings - without a restart, and can be performed by clicking the Execute - button and confirming the prompt which follows. - - - -
- -
- - LoggingManagement MBean - - - - - The LoggingManagement MBean is available on newer servers, and - accessible by admin level users. It allows live alteration of the - logging behaviour, both at a Runtime-only level and at the - configuration file level. The latter can optionally affect the - Runtime configuration, either through use of the servers - automated LogWatch ability which detects changes to the - configuration file and reloads it, or by manually requesting a - reload. This functionality is split across two management tabs, - Runtime Options and ConfigurationFile Options. - -
- Runtime - Options - - - - - - - The Runtime Options tab allows manipulation of the logging - settings without affecting the configuration files (this means - the changes will be lost when the server restarts), and gives - individual access to every Logger active within the server. - - As shown in the figure above, the table in this tab presents the - Effective Level of each Logger. This is because the Loggers form - a hierarchy in which those without an explicitly defined (in the - logging configuration file) Level will inherit the Level of their - immediate parent; that is, the Logger whose full name is a prefix - of their own, or if none satisfy that condition then the - RootLogger is their parent. As example, take the - org.apache.qpid Logger. It is parent to all those below - it which begin with org.apache.qpid and unless they have - a specific Level of their own, they will inherit its Level. This - can be seen in the figure, whereby all the children Loggers - visible have a level of WARN just like their parent, but the - RootLogger Level is INFO; the children have inherited the WARN - level from org.apache.qpid rather than INFO from the - RootLogger. - - To aid with this distinction, the Logger Levels that are - currently defined in the configuration file are highlighted in - the List. Changing these levels at runtime will also change the - Level of all their children which haven't been set their own - Level using the runtime options. In the latest versions of the - LoggingManagement MBean, it is possible to restore a child logger - that has had an explicit level se, to inheriting that of its - parent by setting it to an INHERITED level that removes any - previously set Level of its own. - - - - In order to set one of more Loggers to a new Level, they should - be selected in the table (or double click an individual Logger to - modify it) and the Edit Selected Logger(s) button - pressed to load the dialog shown above. At this point, any of the - available Levels supported by the server can be applied to the - Loggers selected and they will immediately update, as will any - child Loggers without their own specific Level. - - The RootLogger can be similarly edited using the button at the - bottom left of the window. - -
- -
- ConfigurationFile - Options - - - - - The ConfigurationFile Options tab allows alteration of the Level - settings for the Loggers defined in the configuration file, - allowing changes to persist following a restart of the server. - Changes made to the configuration file are only applied - automatically while the sever is running if it was configured to - enable the LogWatch capability, meaning it will monitor the - configuration file for changes and apply the new configuration - when the change is detected. If this was not enabled, the changes - will be picked up when the server is restarted. The status of the - LogWatch feature is shown at the bottom of the tab. - Alternatively, in the latest versions of the LoggingManagement - MBean it is possible to reload the logging configuration file on - demand. - - Manipulating the Levels is as on the Runtime Options tab, either - double-click an individual Logger entry or select multiple - Loggers and use the button to load the dialog to set the new - Level. - - - - One issue to note of when reloading the configuration file - settings, either automatically using LogWatch or manually, is - that any Logger set to a specific Level using the Runtime Options - tab that is not defined in the configuration file will maintain - that Level when the configuration file is reloaded. In other - words, if a Logger is defined in the configuration file, then the - configuration file will take precedence at reload, otherwise the - Runtime options take precedence. - - This situation will be immediately obvious by examining the - Runtime Options tab to see the effective Level of each Logger - – unless it has been altered with the RuntimeOptions or - specifically set in the configuration file, a Logger Level should - match that of its parent. In the latest versions of the - LoggingManagement MBean, it is possible to use the RuntimeOptions - to restore a child logger to inheriting from its parent by - setting it with an INHERITED level that removes any previously - set Level of its own. - - -
-
- - - -
- ServerInformation MBean - - - - - - - The ServerInformation MBean currently only conveys various pieces - of version information to allow precise identification of the - server version and its management capabilities. In future it is - likely to convey additional server-wide details and/or - functionality. - -
- -
- - UserManagement MBean - - - - - The UserManagement MBean is accessible by admin level users, and - allows manipulation of existing user accounts and creation of new - user accounts. - - - - - To add a new user, press the Add New User button, which - will load the dialog shown below. - - - - Here you may enter the new users Username, Password, and select - their JMX Management Rights. This controls whether or not they - have access to the management interface, and if so what - capabilities are accessible. Read Only access allows - undertaking any operations that do not alter the server state, - such as viewing messages. Read + Write access allows use - of all operations which are not deemed admin-only (such as those - in the UserManagement MBean itself). Admin access allows - a user to utilize any operation, and view the admin-only MBeans - (currently these are ConfigurationManagement, LoggingManagement, - and UserManagement). - - One or more users at a time may be deleted by selecting them in - the table and clicking the Delete User(s) button. The - console will then prompt for confirmation before undertaking the - removals. Similarly, the access rights for one or more users may - be updated by selecting them in the table and clicking the - Set Rights button. The console will then display a - dialog enabling selection of the new access level and - confirmation to undertake the update. - - An individual user password may be updated by selecting the user - in the table in and clicking the Set Password button. - The console will then display a dialog enabling input of the new - password and confirmation to undertake the update. - - - The server caches the user details in memory to aid performance. - If may sometimes be necessary to externally modify the password - and access right files on disk. In order for these changes to be - known to the server without a restart, it must be instructed to - reload the file contents. This can be done using the provided - Reload User Details button (on older servers, only the - management rights file is reloaded, on newer servers both files - are. The description on screen will indicate the behaviour). - After pressing this button the console will seek confirmation - before proceeding. - -
- - -
- - VirtualHostManager MBean - - - - - Each VirtualHost in the server has an associated - VirtualHostManager MBean. This allows viewing, creation, and - deletion of Queues and Exchanges within the VirtualHost. - - Clicking the Create button in the Queue section will - open a dialog allowing specification of the Name, Owner - (optional), and durability properties of the new Queue, and - confirmation of the operation. - - One or more Queues may be deleted by selecting them in the table - and clicking the Delete button. This will unregister the - Queue bindings, remove the subscriptions and delete the Queue(s). - The console will prompt for confirmation before undertaking the - operation. - - - - Clicking the Create button in the Exchange section will - open a dialog allowing specification of the Name, Type, and - Durable attributes of the new Exchange, and confirmation of the - operation. - - One or more Exchanges may be deleted by selecting them in the - table and clicking the Delete button. This will - unregister all the related channels and Queue bindings then - delete the Exchange(s). The console will prompt for confirmation - before undertaking the operation. - - - Double-clicking on a particular Queue or Exchange name in the - tables will open the MBean representing it. - -
- - - -
- - Notifications - - - - - MBeans on the server can potentially send Notifications that - users may subscribe to. When managing an individual MBean that - offers Notifications types for subscription, the console supplies - a Notifications tab to allow (un)subscription to the - Notifications if desired and viewing any that are received - following subscription. - - In order to provide quicker access to/awareness of any received - Notifications, each VirtualHost area in the connection tree has a - Notifications area that aggregates all received Notifications for - MBeans in that VirtualHost. An example of this can be seen in the - figure below. - - - - All received Notifications will be displayed until such time as - the user removes them, either in this aggregated view, or in the - Notifications area of the individual MBean that generated the - Notification. - - They may be cleared selectively or all at once. To clear - particular Notifications, they should be selected in the table - before pressing the Clear button. To clear all - Notifications, simply press the Clear button without - anything selected in the table, at which point the console will - request confirmation of this clear-all action. - -
- -
- Managing - Queues - - - - - As mentioned in earlier discussion of Navigation, Queue MBeans - can be opened either by double clicking an entry in the Queues - selection area, or adding a queue to the tree as a favourite and - clicking on its tree node. Unique to the Queue selection screen - is the ability to view additional attributes beyond just that of - the Queue Name. This is helpful for determining which Queues - satisfy a particular condition, e.g. having <X> messages on - the queue. The example below shows the selection view with - additional attributes Consumer Count, Durable, MessageCount, - and QueueDepth (selected using the Select - Attributes button at the bottom right corner of the - table). - - - - Upon opening a Queue MBean, the Attributes tab is displayed, as - shown below. This allows viewing the value all attributes, - editing those which are writable values (highlighted in blue) if - the users management permissions allow, viewing descriptions of - their purpose, and graphing certain numerical attribute values as - they change over time. - - - - The next tab contains the operations that can be performed on the - queue. The main table serves as a means of viewing the messages - on the queue, and later for selecting specific messages to - operate upon. It is possible to view any desired range of - messages on the queue by specifying the visible range using the - fields at the top and pressing the Set button. Next to - this there are helper buttons to enable faster browsing through - the messages on the queue; these allow moving forward and back by - whatever number of messages is made visible by the viewing range - set. The Queue Position column indicates the position of each - message on the queue, but is only present when connected to newer - servers as older versions cannot provide the necessary - information to show this (unless only a single message position - is requested). - - - - Upon selecting a message in the table, its header properties and - redelivery status are updated in the area below the table. Double - clicking a message in the table (or using the View Message - Content button to its right) will open a dialog window - displaying the contents of the message. - - One or more messages can be selected in the table and moved to - another queue in the VirtualHost by using the Move - Message(s) button, which opens a dialog to enable selection - of the destination and confirmation of the operation. Newer - servers support the ability to similarly copy the selected - messages to another queue in a similar fashion, or delete the - selected messages from the queue after prompting for - confirmation. - - Finally, all messages (that have not been acquired by consumers) - on the queue can be deleted using the Clear Queue - button, which will generate a prompt for confirmation. On newer - servers, the status bar at the lower left of the application will - report the number of messages actually removed. - -
- - -
- - Managing Exchanges - - - - Exchange MBeans are opened for management operations in similar - fashion as described for Queues, again showing an Attributes tab - initially, with the Operations tab next: - - - - Of the four default Exchange Types (direct, fanout, headers, - and topic) all but headers have their bindings - presented in the format shown above. The left table provides the - binding/routing keys present in the exchange. Selecting one of - these entries in the table prompts the right table to display all - the queues associated with this key. Pressing the Create - button opens a dialog allowing association of an existing queue - with the entered Binding. - - - - The headers Exchange type (default instantiation - amq.match or amq.headers) is presented as below: - - - - In the previous figure, the left table indicates the binding - number, and the Queue associated with the binding. Selecting one - of these entries in the table prompts the right table to display - the header values that control when the binding matches an - incoming message. - - - - Pressing the Create button when managing a - headers Exchange opens a dialog allowing creation of a - new binding, associating an existing Queue with a particular set - of header keys and values. The x-match key is required, - and instructs the server whether to match the binding with - incoming messages based on ANY or ALL of the further key-value - pairs entered. If it is desired to enter more than 4 pairs, you - may press the Add additional field button to create a - new row as many times as is required. - - When managing a headers Exchange, double clicking an - entry in the left-hand table will open the MBean for the Queue - specified in the binding properties. - - When managing another Exchange Type, double clicking the Queue - Name in the right-hand table will open the MBean of the Queue - specified. - -
- -
- - Managing Connections - - - - - Exchange MBeans are opened for management operations in similar - fashion as described for Queues, again showing an Attributes tab - initially, with the Operations tab next, and finally a - Notifications tab allowing subscription and viewing of - Notifications. The Operations tab can be seen in the figure - below. - - - The main table shows the properties of all the Channels that are - present on the Connection, including whether they are - Transactional, the Number of Unacked Messages - on them, and the Default Queue if there is one (or - null if there is not). - - The main operations supported on a connection are Commiting and - Rolling Back of Transactions on a particular Channel, if the - Channel is Transactional. This can be done by selecting a - particular Channel in the table and pressing the Commit - Transactions or Rollback Transactions buttons at - the lower right corner of the table, at which point the console - will prompt for confirmation of the action. These buttons are - only active when the selected Channel in the table is - Transactional. - - The final operation supported is closing the Connection. After - pressing the Close Connection button, the console will - prompt for confirmation of the action. If this is carried out, - the MBean for the Connection being managed will be removed from - the server. The console will be notified of this by the server - and display an information dialog to that effect, as it would if - any other MBean were to be unregistered whilst being viewed. - - Double clicking a row in the table will open the MBean of the - associated Default Queue if there is one. - - -
-
diff --git a/doc/book/src/java-broker/Qpid-JMX-Management-Console.xml b/doc/book/src/java-broker/Qpid-JMX-Management-Console.xml deleted file mode 100644 index fb46f4a01a..0000000000 --- a/doc/book/src/java-broker/Qpid-JMX-Management-Console.xml +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - - Qpid JMX Management Console - - -
- - Qpid JMX Management Console - -
- - - Overview - - - - The Qpid JMX Management Console is a standalone Eclipse - RCP application that communicates with the broker using - JMX. - - - - - - - - -
-
- diff --git a/doc/book/src/java-broker/Qpid-Java-Broker-Management-CLI.xml b/doc/book/src/java-broker/Qpid-Java-Broker-Management-CLI.xml deleted file mode 100644 index 84c4b7b7a4..0000000000 --- a/doc/book/src/java-broker/Qpid-Java-Broker-Management-CLI.xml +++ /dev/null @@ -1,159 +0,0 @@ - - - -
- Qpid Java Broker Management CLI - -
- How to - build Apache Qpid CLI - - - -
- Build - Instructions - General - - - - At the very beginning please build Apache Qpid by refering this - installation guide from here . - - After successfully build Apache Qpid you'll be able to start - Apache Qpid Java broker,then only you are in a position to use - Qpid CLI. - -
- -
- Check - out the Source - - - - First check out the source from subversion repository. Please - visit the following link for more information about different - versions of Qpid CLI. - - - -
- -
- Prerequisites - - - - For the broker code you need JDK 1.5.0_15 or later. You should - set JAVA_HOME and include the bin directory in your PATH. - - Check it's ok by executing java -v ! - -
- -
- Building - Apache Qpid CLI - - - - This project is currently having only an ant build system.Please - install ant build system before trying to install Qpid CLI. - -
- - - -
- Compiling - - - - To compile the source please run following command - - -ant compile - - - To compile the test source run the following command - - -ant compile-tests - -
- - -
- Running CLI - - - - After successful compilation set QPID_CLI environment variable to - the main source directory.(set the environment variable to the - directory where ant build script stored in the SVN - checkout).Please check whether the Qpid Java broker is up an - running in the appropriate location and run the following command - to start the Qpid CLI by running the qpid-cli script in the bin - directory. - - $QPID_CLI/bin/qpid-cli -h <hostname of the broker> -p - <broker running port> - For more details please have a look in to README file which ships - with source package of Qpid CLI. - -
- - -
- Other - ant targets - - - For now we are supporting those ant targets. - - - - ant clean - Clean the complete build including CLI build and test build. - - - ant jar - Create the jar file for the project without test cases. - - - ant init - Create the directory structure for build. - - - ant compile-tests - This compiles all the test source. - - - ant test - Run all the test cases. - - - - -
-
-
diff --git a/doc/book/src/java-broker/Qpid-Java-Build-How-To.xml b/doc/book/src/java-broker/Qpid-Java-Build-How-To.xml deleted file mode 100644 index 9f3625760a..0000000000 --- a/doc/book/src/java-broker/Qpid-Java-Build-How-To.xml +++ /dev/null @@ -1,365 +0,0 @@ - - - -
- Qpid Java Build How To - - -
- Build - Instructions - General - - -
- Check out the - source - - - Firstly, check the source for Qpid out of our subversion - repository: - - - -
-
- Prerequisites - - - For the broker code you need JDK 1.5.0_15 or later. You should - set JAVA_HOME and include the bin directory in your PATH. - - Check it's ok by executing java -v ! - - If you are wanting to run the python tests against the broker you - will of course need a version of python. - -
-
- -
- Build - Instructions - Trunk - - - Our build system has reverted to ant as of May 2008. - - The ant target 'help' will tell you what you need to know about - the build system. - -
- Ant Build - Scripts - - - Currently the Qpid java project builds using ant. - - The ant build system is set up in a modular way, with a top level - build script and template for module builds and then a module - level build script which inherits from the template. - - So, at the top level there are: - <tgroup cols="2"> - <tbody> - <row> - <entry> - File - </entry> - <entry> - Description - </entry> - </row> - <row> - <entry> - build.xml - </entry> - <entry> - Top level build file for the project which defines all the - build targets - </entry> - </row> - <row> - <entry> - common.xml - </entry> - <entry> - Common properties used throughout the build system - </entry> - </row> - <row> - <entry> - module.xml - </entry> - <entry> - Template used by all modules which sets up properties for - module builds - </entry> - </row> - </tbody> - </tgroup></table><para> - Then, in each module subdirectory there is: - </para><table><title/><tgroup cols="2"> - <tbody> - <row> - <entry> - File - </entry> - <entry> - Description - </entry> - </row> - <row> - <entry> - build.xml - </entry> - <entry> - Defines all the module values for template properties - </entry> - </row> - </tbody> - </tgroup></table> -<!--h2--></section> - <section role="h2" id="QpidJavaBuildHowTo-Buildtargets"><title> - Build targets - - - The main build targets you are probably interested in are: -
<tgroup cols="2"> - <tbody> - <row> - <entry> - Target - </entry> - <entry> - Description - </entry> - </row> - <row> - <entry> - build - </entry> - <entry> - Builds all source code for Qpid - </entry> - </row> - <row> - <entry> - test - </entry> - <entry> - Runs the testsuite for Qpid - </entry> - </row> - </tbody> - </tgroup></table><para> - So, if you just want to compile everything you should run the - build target in the top level build.xml file. - </para><para> - If you want to build an installable version of Qpid, run the - archive task from the top level build.xml file. - </para><para> - If you want to compile an individual module, simply run the build - target from the appropriate module e.g. to compile the broker - source - </para> -<!--h2--></section> - <section role="h2" id="QpidJavaBuildHowTo-ConfiguringEclipse"><title> - Configuring - Eclipse - - - 1. Run the ant build from the root directory of Java trunk. - 2. New project -> create from existing file system for broker, - common, client, junit-toolkit, perftests, systests and each - directory under management - 4. Add the contents of lib/ to the build path - 5. Setup Generated Code - 6. Setup Dependencies - -
- Generated Code - - - The Broker and Common packages both depend on generated code. - After running 'ant' the build/scratch directory will contain this - generated code. - For the broker module add build/scratch/broker/src - For the common module add build/scratch/common/src - -
-
- Dependencies - - - These dependencies are correct at the time of writting however, - if things are not working you can check the dependencies by - looking in the modules build.xml file: - - -for i in `find . -name build.xml` ; do echo "$i:"; grep module.depends $i ; done - - - The module.depend value will detail which other modules - are dependencies. - - broker - - common - - management/common - - - client - - Common - - - systest - - client - - management/common - - broker - - broker/test - - common - - junit-toolkit - - management/tools/qpid-cli - - - perftests - - systests - - client - - broker - - common - - junit-toolkit - - - management/eclipse-plugin - - broker - - common - - management/common - - - management/console - - common - - client - - - management/agent - - common - - client - - - management/tools/qpid-cli - - common - - management/common - - - management/client - - common - - client - - - integrationtests - - systests - - client - - common - - junit-toolkit - - - testkit - - client - - broker - - common - - - tools - - client - - common - - - client/examples - - common - - client - - - broker-plugins - - client - - management/common - - broker - - common - - junit-toolkit - - -
- - -
- What next ? - - - If you want to run your built Qpid package, see our for details of - how to do that. - - If you want to run our tests, you can use the ant test or - testreport (produces a useful report) targets. - - -
- - diff --git a/doc/book/src/java-broker/Qpid-Java-FAQ.xml b/doc/book/src/java-broker/Qpid-Java-FAQ.xml deleted file mode 100644 index 2940e58138..0000000000 --- a/doc/book/src/java-broker/Qpid-Java-FAQ.xml +++ /dev/null @@ -1,890 +0,0 @@ - - - -
- Qpid Java FAQ - - -
- Purpose - - Here are a list of commonly asked questions and answers. Click on - the the bolded questions for the answer to unfold. If you have - any questions which are not on this list, please email our - qpid-user list. - - -
- What is Qpid ? - - - - The java implementation of Qpid is a pure Java message broker - that implements the AMQP protocol. Essentially, Qpid is a robust, - performant middleware component that can handle your messaging - traffic. - - It currently supports the following features: - - High performance header-based routing for messages - - All features required by the JMS 1.1 specification. Qpid - passes all tests in the Sun JMS compliance test suite - - Transaction support - - Persistence using the high performance Berkeley DB Java - Edition. The persistence layer is also pluggable should an - alternative implementation be required. The BDB store is - available from the page - - Pluggable security using SASL. Any Java SASL provider can be - used - - Management using JMX and a custom management console built - using Eclipse RCP - - Naturally, interoperability with other clients including the - Qpid .NET, Python, Ruby and C++ implementations - - -
- -
- Why am I getting a ConfigurationException at broker startup ? - - -
- InvocationTargetException - - - If you get a java.lang.reflect.InvocationTargetException on - startup, wrapped as ConfigurationException like this: - - -Error configuring message broker: org.apache.commons.configuration.ConfigurationException: java.lang.reflect.InvocationTargetException -2008-09-26 15:14:56,529 ERROR [main] server.Main (Main.java:206) - Error configuring message broker: org.apache.commons.configuration.ConfigurationException: java.lang.reflect.InvocationTargetException -org.apache.commons.configuration.ConfigurationException: java.lang.reflect.InvocationTargetException -at org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabase(ConfigurationFilePrincipalDatabaseManager.java:158) -at org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabases(ConfigurationFilePrincipalDatabaseManager.java:87) -at org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.<init>(ConfigurationFilePrincipalDatabaseManager.java:56) -at org.apache.qpid.server.registry.ConfigurationFileApplicationRegistry.initialise(ConfigurationFileApplicationRegistry.java:117) -at org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:79) -at org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:67) -at org.apache.qpid.server.Main.startup(Main.java:260) -at org.apache.qpid.server.Main.execute(Main.java:196) -at org.apache.qpid.server.Main.<init>(Main.java:96) -at org.apache.qpid.server.Main.main(Main.java:454) -at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) -at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -at java.lang.reflect.Method.invoke(Method.java:597) -at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) -Caused by: java.lang.reflect.InvocationTargetException -at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) -at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -at java.lang.reflect.Method.invoke(Method.java:597) -at org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabase(ConfigurationFilePrincipalDatabaseManager.java:148) - - - .. then it means you have a missing password file. - - You need to create a password file for your deployment and update - your config.xml to reflect the location of the password file for - your instance. - - The config.xml can be a little confusing in terms of element - names and file names for passwords. - - To do this, you need to edit the passwordDir element for the - broker, which may have a comment to that effect: - - -<passwordDir><!-- Change to the location --></passwordDir> - - - The file should be named passwd by default but if you want to you - can change this by editing this element: - - -<value>${passwordDir}/passwd</value> - -
- - -
- Cannot locate configuration source null/virtualhosts.xml - - - - If you get this message, wrapped inside a ConfigurationException - then you've come across a known issue, see JIRA - - The work around is to use a qualified path as the parameter value - for your -c option, rather than (as you migth be) starting the - broker from your installed etc directory. Even going up one level - and using a path relative to your £QPID_HOME directory - would sort this e.g qpid-server -c ./etc/myconfig.xml - -
-
- -
- How do I run - the Qpid broker ? - - - - The broker comes with a script for unix/linux/cygwin called - qpid-server, which can be found in the bin directory of the - installed package. This command can be executed without any - paramters and will then use the default configuration file - provided on install. - - For the Windows OS, please use qpid-server.bat. - - There's no need to set your classpath for QPID as the scripts - take care of that by adding jar's with classpath defining - manifest files to your classpath. - - For more information on running the broker please see our - page. - -
- -
- How can I - create a connection using a URL ? - - - - Please see the documentation. - -
- -
- How - do I represent a JMS Destination string with QPID ? - - -
- Queues - - - - A queue can be created in QPID using the following URL format. - - direct://amq.direct/<Destination>/<Queue - Name> - - For example: - direct://amq.direct/<Destination>/simpleQueue - - Queue names may consist of any mixture of digits, letters, and - underscores. - - The is described in more - detail on it's own page. - -
- -
- Topics - - - - A topic can be created in QPID using the following URL format. - - topic://amq.topic/<Topic Subscription>/ - - The topic subscription may only contain the letters A-Z and a-z - and digits 0-9. - - The topic subscription is formed from a series of words that may - only contain the letters A-Z and a-z and digits 0-9. - The words are delimited by dots. Each dot represents a new level. - - For example: stocks.nyse.ibm - - Wildcards can be used on subscription with the following meaning. - - match a single level - # match zero or more levels - - - For example: - With two clients - 1 - stocks.*.ibm - 2 - stocks.#.ibm - - Publishing stocks.nyse.ibm will be received by both - clients but stocks.ibm and stocks.world.us.ibm - will only be received by client 2. - - The topic currently does not support wild cards. - -
-
- -
- How do I - connect to the broker using JNDI ? - - - - see - -
- -
- I'm using Spring and Weblogic - can you help me with the - configuration for moving over to Qpid ? - - - - Here is a donated Spring configuration file appContext.zip - which shows the config for Qpid side by side with - Weblogic. HtH ! - -
- -
- How do - I configure the logging level for Qpid ? - - - - The system property - - -amqj.logging.level - - - can be used to configure the logging level. - For the broker, you can use the environment variable - AMQJ_LOGGING_LEVEL which is picked up by the qpid-run script - (called by qpid-server to start the broker) at runtime. - - For client code that you've written, simply pass in a system - property to your command line to set it to the level you'd like - i.e. - - --Damqj.logging.level=INFO - - - The log level for the broker defaults to INFO if the env variable - is not set, but you may find that your log4j properties affect - this. Setting the property noted above should address this. - -
- -
- How can I configure my application to use Qpid client - logging? - - - - If you don't already have a logging implementation in your - classpath you should add slf4-log4j12-1.4.0.jar and - log4j-1.2.12.jar. - -
- -
- How can I - configure the broker ? - - - - The broker configuration is contained in the - <installed-dir>/etc/config.xml file. You can copy and edit - this file and then specify your own configuration file as a - parameter to the startup script using the -c flag i.e. - qpid-server -c <your_config_file's_path> - - For more detailed information on configuration, please see - - - - -
- -
- What ports - does the broker use? - - - - The broker defaults to use port 5672 at startup for AMQP - traffic. - If the management interface is enabled it starts on port 8999 by - default. - - The JMX management interface actually requires 2 ports to - operate, the second of which is indicated to the client - application during connection initiation to the main (default: - 8999) port. Previously this second port has been chosen at random - during broker startup, however since Qpid 0.5 this has been fixed - to a port 100 higher than the main port(ie Default:9099) in order - to ease firewall navigation. - -
- -
- How - can I change the port the broker uses at runtime ? - - - - The broker defaults to use port 5672 at startup for AMQP - traffic. - The broker also uses port 8999 for the JMX Management interface. - - To change the AMQP traffic port use the -p flag at startup. To - change the management port use -m - i.e. qpid-server -p <port_number_to_use> -m - <port_number_to_use> - - Use this to get round any issues on your host server with port - 5672/8999 being in use/unavailable. - - For additional details on what ports the broker uses see FAQ - entry. - For more detailed information on configuration, please see - - -
- -
- What command line options can I pass into the qpid-server - script ? - - - - The following command line options are available: - - - - The following options are available: -
- - Command Line Options - - - - - - - Option - - - Long Option - - - Description - - - - - b - - - bind - - - Bind to the specified address overriding any value in the - config file - - - - - c - - - config - - - Use the given configuration file - - - - - h - - - help - - - Prints list of options - - - - - l - - - logconfig - - - Use the specified log4j.xml file rather than that in the - etc directory - - - - - m - - - mport - - - Specify port to listen on for the JMX Management. Overrides - value in config file - - - - - p - - - port - - - Specify port to listen on. Overrides value in config file - - - - - v - - - version - - - Print version information and exit - - - - - w - - - logwatch - - - Specify interval for checking for logging config changes. - Zero means no checking - - - -
-
- -
- How do I authenticate with the broker ? What user id & - password should I use ? - - - - You should login as user guest with password guest - -
- -
- How do I create queues that will always be instantiated at - broker startup ? - - - - You can configure queues which will be created at broker startup - by tailoring a copy of the virtualhosts.xml file provided in the - installed qpid-version/etc directory. - - So, if you're using a queue called 'devqueue' you can ensure that - it is created at startup by using an entry something like this: - - -<virtualhosts> - <default>test</default> - <virtualhost> - <name>test</name> - <test> - <queue> - <name>devqueue</name> - <devqueue> - <exchange>amq.direct</exchange> - <maximumQueueDepth>4235264</maximumQueueDepth> <!-- 4Mb --> - <maximumMessageSize>2117632</maximumMessageSize> <!-- 2Mb --> - <maximumMessageAge>600000</maximumMessageAge> <!-- 10 mins --> - </devqueue> - </queue> - </test> - </virtualhost> -</virtualhosts> - - - Note that the name (in thie example above the name is 'test') - element should match the virtualhost that you're using to create - connections to the broker. This is effectively a namespace used - to prevent queue name clashes etc. You can also see that we've - set the 'test' virtual host to be the default for any connections - which do not specify a virtual host (in the <default> tag). - - You can amend the config.xml to point at a different - virtualhosts.xml file by editing the <virtualhosts/> - element. - - So, for example, you could tell the broker to use a file in your - home directory by creating a new config.xml file with the - following entry: - - <virtualhosts>/home/myhomedir/virtualhosts.xml</virtualhosts> - - You can then pass this amended config.xml into the broker at - startup using the -c flag i.e. - qpid-server -c <path>/config.xml - -
- -
- How do I - create queues at runtime? - - - - Queues can be dynamically created at runtime by creating a - consumer for them. After they have been created and bound (which - happens automatically when a JMS Consumer is created) a publisher - can send messages to them. - -
- -
- How do I tune - the broker? - - - - There are a number of tuning options available, please see the - page for more information. - -
- -
- Where do - undeliverable messages end up ? - - - - At present, messages with an invalid routing key will be returned - to the sender. If you register an exception listener for your - publisher (easiest to do by making your publisher implement the - ExceptionListener interface and coding the onException method) - you'll see that you end up in onException in this case. You can - expect to be catching a subclass of - org.apache.qpid.AMQUndeliveredException. - -
- -
- Can I configure the name of the Qpid broker log file at - runtime ? - - - - If you simply start the Qpid broker using the default - configuration, then the log file is written to - $QPID_WORK/log/qpid.log - - This is not ideal if you want to run several instances from one - install, or acrhive logs to a shared drive from several hosts. - - To make life easier, there are two optional ways to configure the - naming convention used for the broker log. - - -
- Setting a prefix - or suffix - - - - Users should set the following environment variables before - running qpid-server: - - QPID_LOG_PREFIX - will prefix the log file name with the - specified value e.g. if you set this value to be the name of your - host (for example) it could look something like host123qpid.log - - QPID_LOG_SUFFIX - will suffix the file name with the specified - value e.g. if you set this value to be the name of your - application (for example) if could look something like - qpidMyApp.log - -
- -
- Including the PID - - - - Setting either of these variables to the special value PID will - introduce the process id of the java process into the file name - as a prefix or suffix as specified** - -
-
- -
- My - client application appears to have hung? - - - - The client code currently has various timeouts scattered - throughout the code. These can cause your client to appear like - it has hung when it is actually waiting for the timeout ot - compelete. One example is when the broker becomes non-responsive, - the client code has a hard coded 2 minute timeout that it will - wait when closing a connection. These timeouts need to be - consolidated and exposed. see - -
- -
- How do I - contact the Qpid team ? - - - - For general questions, please subscribe to the - users@qpid.apache.org mailing list. - - For development questions, please subscribe to the - dev@qpid.apache.org mailing list. - - More details on these lists are available on our - page. - -
- -
- How can I change a user's password while the broker is up ? - - - - You can do this via the . To - do this simply log in to the management console as an admin user - (you need to have created an admin account in the - jmxremote.access file first) and then select the 'UserManagement' - mbean. Select the user in the table and click the Set Password - button. Alternatively, update the password file and use the - management console to reload the file with the button at the - bottom of the 'UserManagement' view. In both cases, this will - take effect when the user next logs in i.e. will not cause them - to be disconnected if they are already connected. - - For more information on the Management Console please see our - - -
- -
- How do I know if there is a consumer for a message I am going - to send? - - - - Knowing that there is a consumer for a message is quite tricky. - That said using the qpid.jms.Session#createProducer with - immediate and mandatory set to true will get you part of the way - there. - - If you are publishing to a well known queue then immediate will - let you know if there is any consumer able to pre-fetch that - message at the time you send it. If not it will be returned to - you on your connection listener. - - If you are sending to a queue that the consumer creates then the - mandatory flag will let you know if they have not yet created - that queue. - - These flags will not be able to tell you if the consuming - application has received the message and is able to process it. - -
- -
- How - can I inspect the contents of my MessageStore? - - - - The management console can be used to interogate an active - broker and browse the contents of a queue.See the - page for further details. - -
- -
- Why are - my transient messages being so slow? - - - - You should check that you aren't sending persistent messages, - this is the default. If you want to send transient messages you - must explicitly set this option when instantiating your - MessageProducer or on the send() method. - -
- -
- Why - does my producer fill up the broker with messages? - - - - Switch on producer flow control to prevent temporary spikes in - message production over-filling the broker. - - Of course, if the long-term rate of message production exceeds - the rate of message - consumption then that is an architectural problem that can only - be temporarily mitigated by producer flow control. - -
- -
- The - broker keeps throwing an OutOfMemory exception? - - - - The broker can no longer store any more messages in memory. This - is particular evident if you are using the MemoryMessageStore. To - alleviate this issue you should ensure that your clients are - consuming all the messages from the broker. - - You may also want to increase the memory allowance to the broker - though this will only delay the exception if you are publishing - messages faster than you are consuming. See for - details of changing the memory settings. - -
- -
- Why am I getting a broker side exception when I try to - publish to a queue or a topic ? - - - - If you get a stack trace like this when you try to publish, then - you may have typo'd the exchange type in your queue or topic - declaration. Open your virtualhosts.xml and check that the - - -<exchange>amq.direct</exchange> - - - -2009-01-12 15:26:27,957 ERROR [pool-11-thread-2] protocol.AMQMinaProtocolSession (AMQMinaProtocolSession.java:365) - Unexpected exception while processing frame. Closing connection. -java.lang.NullPointerException - at org.apache.qpid.server.security.access.PrincipalPermissions.authorise(PrincipalPermissions.java:398) - at org.apache.qpid.server.security.access.plugins.SimpleXML.authorise(SimpleXML.java:302) - at org.apache.qpid.server.handler.QueueBindHandler.methodReceived(QueueBindHandler.java:111) - at org.apache.qpid.server.handler.ServerMethodDispatcherImpl.dispatchQueueBind(ServerMethodDispatcherImpl.java:498) - at org.apache.qpid.framing.amqp_8_0.QueueBindBodyImpl.execute(QueueBindBodyImpl.java:167) - at org.apache.qpid.server.state.AMQStateManager.methodReceived(AMQStateManager.java:204) - at org.apache.qpid.server.protocol.AMQMinaProtocolSession.methodFrameReceived(AMQMinaProtocolSession.java:295) - at org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:93) - at org.apache.qpid.server.protocol.AMQMinaProtocolSession.frameReceived(AMQMinaProtocolSession.java:235) - at org.apache.qpid.server.protocol.AMQMinaProtocolSession.dataBlockReceived(AMQMinaProtocolSession.java:191) - at org.apache.qpid.server.protocol.AMQPFastProtocolHandler.messageReceived(AMQPFastProtocolHandler.java:244) - at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703) - at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) - at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) - at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) - at org.apache.qpid.pool.PoolingFilter.messageReceived(PoolingFilter.java:371) - at org.apache.mina.filter.ReferenceCountingIoFilter.messageReceived(ReferenceCountingIoFilter.java:96) - at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) - at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) - at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) - at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:60) - at org.apache.mina.filter.codec.QpidProtocolCodecFilter.messageReceived(QpidProtocolCodecFilter.java:174) - at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) - at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) - at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) - at org.apache.qpid.pool.Event$ReceivedEvent.process(Event.java:86) - at org.apache.qpid.pool.Job.processAll(Job.java:110) - at org.apache.qpid.pool.Job.run(Job.java:149) - at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) - at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) - at java.lang.Thread.run(Thread.java:619) - -
- -
- Why - is there a lot of AnonymousIoService threads - - - - These threads are part of the thread pool used by Mina to process - the socket. In the future we may provide tuning guidelines but at - this point we have seen no performance implications from the - current configuration. As the threads are part of a pool they - should remain inactive until required. - -
- -
- "unable to certify the provided SSL certificate using the - current SSL trust store" when connecting the Management Console - to the broker. - - - - You have not configured the console's SSL trust store properly, - see for - more details. - -
- -
- Can a use TCP_KEEPALIVE or AMQP heartbeating to keep my - connection open? - - - - See - - -
-
- - - -
diff --git a/doc/book/src/java-broker/Qpid-Management-Features.xml b/doc/book/src/java-broker/Qpid-Management-Features.xml deleted file mode 100644 index c90d7e97c6..0000000000 --- a/doc/book/src/java-broker/Qpid-Management-Features.xml +++ /dev/null @@ -1,185 +0,0 @@ - - - -
- - Qpid Management Features - - - Management tool: See our for - details of how to use various console options with the Qpid - management features. - - - The management of QPID is categorised into following types- - - - Exchange - - Queue - - Connection - - Broker - - - -  1) Managing and Monitoring Exchanges: Following is - the list of features, which we can have available for managing - and monitoring an Exchange running on a Qpid Server Domain- - - - Displaying the following information for monitoring purpose- - - The list of queues bound to the exchange along with the - routing keys. - - - General Exchange properties(like name, - durable etc). - - - - - Binding an existing queue with the - exchange. - - - - 2) Managing and Monitoring - Queues:  Following are the - features, which we can have for a Queue on a Qpid Server - Domain- - - - - Displaying the following information about - the queue for monitoring purpose- - - - General Queue properties(like name, - durable, etc.) - - - The maximum size of a message that can - be accepted from the message producer. - - - The number of the active consumers - accessing the Queue. - - - The total number of - consumers (Active and Suspended). - - - The number of undelivered messages - in the Queue. - - - The total number of messages received - on the Queue since startup. - - - The maximum number of bytes for - the Queue that can be stored on the Server. - - The maximum number of messages for the Queue that can be - stored on the Server. - - - - - Viewing the messages on the Queue. - - - Deleting message from top of the - Queue. - - - Clearing the Queue. - - - Browsing the DeadMessageQueue - Messages - which are expired or undelivered because of some reason are - routed to the DeadMessageQueue.  This queue can not be - deleted.  [Note: The is open because it depends on how - these kind of messages will be handeled?] - - - - 3) Managing and Monitoring - Connections: Following are the - features, which we can have for a connection on a QPID - Server Domain- - - - - Displaying general connection - properties(like remote address, etc.). - - Setting maximum number of channels allowed for a - connection. - - View all related channels and channel properties. - - Closing a channel. - - Commit or Rollback transactions of a channel, if the channel - is transactional. - - Notification for exceeding the maximum number of - channels. - - Dropping a connection. - - The work for implies that - there are potentially some additional requirements - - Alert when tcp flow control kicks in - - Information available about current memory usage - available through JMX interface - - Dynamic removal of buffer bounds? (fundamentally not - possible with TransportIO) - - Management functionality added to JMX interface - UI - changes? - - - - - - 4) Managing the Broker: Features for the Broker- - - - Creating an Exchange. - - Unregistering an Exchange. - - Creating a Queue. - - Deleting a Queue. - - -
diff --git a/doc/book/src/java-broker/Qpid-Troubleshooting-Guide.xml b/doc/book/src/java-broker/Qpid-Troubleshooting-Guide.xml deleted file mode 100644 index 0920f18798..0000000000 --- a/doc/book/src/java-broker/Qpid-Troubleshooting-Guide.xml +++ /dev/null @@ -1,156 +0,0 @@ - - - -
- - - Qpid Troubleshooting Guide - - -
- I'm getting a java.lang.UnsupportedClassVersionError when I - try to start the broker. What does this mean ? - - - - The QPID broker requires JDK 1.5 or later. If you're seeing this - exception you don't have that version in your path. Set JAVA_HOME - to the correct version and ensure the bin directory is on your - path. - - java.lang.UnsupportedClassVersionError: - org/apache/qpid/server/Main (Unsupported major.minor version - 49.0) - at - java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown - Source) - at - java.security.SecureClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.CodeSource;)Ljava.lang.Class;(SecureClassLoader.java:123) - - at - java.net.URLClassLoader.defineClass(Ljava.lang.String;Lsun.misc.Resource;)Ljava.lang.Class;(URLClassLoader.java:251) - - at - java.net.URLClassLoader.access$100(Ljava.net.URLClassLoader;Ljava.lang.String;Lsun.misc.Resource;)Ljava.lang.Class;(URLClassLoader.java:55) - - at java.net.URLClassLoader$1.run()Ljava.lang.Object; - (URLClassLoader.java:194) - at - jrockit.vm.AccessController.do_privileged_exc(Ljava.security.PrivilegedExceptionAction;Ljava.security.AccessControlContext;I)Ljava.lang.Object;(Unknown - Source) - at - jrockit.vm.AccessController.doPrivileged(Ljava.security.PrivilegedExceptionAction;Ljava.security.AccessControlContext;)Ljava.lang.Object;(Unknown - Source) - at - java.net.URLClassLoader.findClass(Ljava.lang.String;)Ljava.lang.Class;(URLClassLoader.java:187) - - at - java.lang.ClassLoader.loadClass(Ljava.lang.String;Z)Ljava.lang.Class; - (Unknown Source) - at - sun.misc.Launcher$AppClassLoader.loadClass(Ljava.lang.String;Z)Ljava.lang.Class;(Launcher.java:274) - - at - java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class; - - (Unknown Source) - at - java.lang.ClassLoader.loadClassFromNative(II)Ljava.lang.Class; - - (Unknown Source) - - -
- -
- I'm having a problem binding to the required host:port at - broker startup ? - - - This error probably indicates that another process is using the - port you the broker is trying to listen on. If you haven't - amended the default configuration this will be 5672. To check - what process is using the port you can use 'netstat -an |grep - 5672'. - - To change the port your broker uses, either edit the config.xml - you are using. You can specify an alternative config.xml from the - one provided in /etc by using the -c flag i.e. qpid-server -c - <my config file path>. - - You can also amend the port more simply using the -p option to - qpid-server i.e. qpid-server -p <my port number' - -
- -
- I'm having problems with my classpath. How can I ensure that - my classpath is ok ? - - - When you are running the broker the classpath is taken care of - for you, via the manifest entries in the launch jars that the - qpid-server configuration file adds to the classpath. - - However, if you are running your own client code and experiencing - classspath errors you need to ensure that the client-launch.jar - from the installed Qpid lib directory is on your classpath. The - manifest for this jar includes the common-launch.jar, and thus - all the code you need to run a client application. - -
- -
- I can't get the broker to start. How can I diagnose the - problem ? - - - Firstly have a look at the broker log file - either on stdout or - in $QPID_WORK/log/qpid.log or in $HOME/log/qpid.log if you - haven't set QPID_WORK. - - You should see the problem logged in here via log4j and a stack - trace. Have a look at the other entries on this page for common - problems. If the log file includes a line like: - - "2006-10-13 09:58:14,672 INFO [main] server.Main (Main.java:343) - - Qpid.AMQP listening on non-SSL address 0.0.0.0/0.0.0.0:5672" - - ... then you know the broker started up. If not, then it didn't. - -
- -
- When I try to send messages to a queue I'm getting a error as - the queue does not exist. What can I do ? - - - In Qpid queues need a consumer before they really exist, unless - you have used the virtualhosts.xml file to specify queues which - should always be created at broker startup. If you don't want to - use this config, then simply ensure that you consume first from - queue before staring to publish to it. See the entry on our - for more details of using the virtualhosts.xml route. - -
- -
diff --git a/doc/book/src/java-broker/Topic-Configuration.xml b/doc/book/src/java-broker/Topic-Configuration.xml deleted file mode 100644 index 1f73bbd7a4..0000000000 --- a/doc/book/src/java-broker/Topic-Configuration.xml +++ /dev/null @@ -1,107 +0,0 @@ - - - -
- Topic Configuration on Java Broker - - New in 0.8 is the ability to define configuration for topics. Currently this is limited to - configuration for slow consumer detection. This configuration is based on the work - designed on the design - wiki. - -
- Topic Identification - A configuration section has two entries that can be used to identify how the - configuration will be applied: 'name' and 'subscriptionName'. - - - <topic> - <name>stocks.us</name> - - - <topic> - <subscriptionName>clientid:mysubscription</subscriptionName> - - - It is also possible to combine these two identifiers to specify a unique subscription to - a given topic. - - - <topic> - <name>stocks.us</name> - <subscriptionName>clientid:mysubscription</subscriptionName> - - -
- -
- Configuration Items - Currently only one element of the designed configuration is processed, that of the - slow consumer detection. This is setup as below using the 'slow-consumer-detection' - element. There are two required types of tag, first the trigger, which is one of - 'depth', 'messageAge' or 'messageCount' and secondly the 'policy'. - - <slow-consumer-detection> - <!-- The maximum depth before which the policy will be applied--> - <depth>4235264</depth> - - <!-- The maximum message age before which the policy will be applied--> - <messageAge>600000</messageAge> - - <!-- The maximum number of message before which the policy will be applied--> - <messageCount>50</messageCount> - - <!-- Policy Selection --> - <policy name="TopicDelete"/> - </slow-consumer-detection> - - - The trigger is used to determine when the policy should be applied. Currently we have - a simple policy 'topicdelete', this will disconnect consumers of topics where their - consumption rate falls sufficiently to hit one of the trigger values. -
- - -
- Limitiations - As of 0.8 the topic configuration is limited to straight string matching. This means - that given the following two topic configuring sections for 'stocks.us' and 'stocks.*' a - subscription for 'stocks.uk' will not match the expected 'stocks.*'. Nor will any - additional configuration listed in 'stocks.*' affect any 'stocks.us' subscriptions. - - <topics> - <topic> - <name>stocks.us</name> - ... - </topic> - <topic> - <name>stocks.*</name> - ... - </topic> - </topics> - - A subscription for 'stocks.us' will only receive configuration settings that are - defined in the 'stocks.us' section. -
- -
diff --git a/doc/book/src/java-broker/commonEntities.xml b/doc/book/src/java-broker/commonEntities.xml new file mode 100644 index 0000000000..a53440a467 --- /dev/null +++ b/doc/book/src/java-broker/commonEntities.xml @@ -0,0 +1,39 @@ + + + + + + + + + + + + + + + + + + + + diff --git a/doc/book/src/java-broker/images/3113098.png b/doc/book/src/java-broker/images/3113098.png deleted file mode 100644 index 7de85030c6..0000000000 Binary files a/doc/book/src/java-broker/images/3113098.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113099.png b/doc/book/src/java-broker/images/3113099.png deleted file mode 100644 index fb6fc65d73..0000000000 Binary files a/doc/book/src/java-broker/images/3113099.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113100.png b/doc/book/src/java-broker/images/3113100.png deleted file mode 100644 index a7d727b854..0000000000 Binary files a/doc/book/src/java-broker/images/3113100.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113101.png b/doc/book/src/java-broker/images/3113101.png deleted file mode 100644 index 30731277c2..0000000000 Binary files a/doc/book/src/java-broker/images/3113101.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113102.png b/doc/book/src/java-broker/images/3113102.png deleted file mode 100644 index f150a21b10..0000000000 Binary files a/doc/book/src/java-broker/images/3113102.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113103.png b/doc/book/src/java-broker/images/3113103.png deleted file mode 100644 index a91efb4306..0000000000 Binary files a/doc/book/src/java-broker/images/3113103.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113104.png b/doc/book/src/java-broker/images/3113104.png deleted file mode 100644 index c5ef12d8b1..0000000000 Binary files a/doc/book/src/java-broker/images/3113104.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113105.png b/doc/book/src/java-broker/images/3113105.png deleted file mode 100644 index b155f9d9a1..0000000000 Binary files a/doc/book/src/java-broker/images/3113105.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113106.png b/doc/book/src/java-broker/images/3113106.png deleted file mode 100644 index 22bcdd084e..0000000000 Binary files a/doc/book/src/java-broker/images/3113106.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113107.png b/doc/book/src/java-broker/images/3113107.png deleted file mode 100644 index cf5dd97e89..0000000000 Binary files a/doc/book/src/java-broker/images/3113107.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113108.png b/doc/book/src/java-broker/images/3113108.png deleted file mode 100644 index c0e5eafde2..0000000000 Binary files a/doc/book/src/java-broker/images/3113108.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113109.png b/doc/book/src/java-broker/images/3113109.png deleted file mode 100644 index 139d81d849..0000000000 Binary files a/doc/book/src/java-broker/images/3113109.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113110.png b/doc/book/src/java-broker/images/3113110.png deleted file mode 100644 index 2207f15cd7..0000000000 Binary files a/doc/book/src/java-broker/images/3113110.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113111.png b/doc/book/src/java-broker/images/3113111.png deleted file mode 100644 index 5737f41caf..0000000000 Binary files a/doc/book/src/java-broker/images/3113111.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113112.png b/doc/book/src/java-broker/images/3113112.png deleted file mode 100644 index d9ee094ab4..0000000000 Binary files a/doc/book/src/java-broker/images/3113112.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113113.png b/doc/book/src/java-broker/images/3113113.png deleted file mode 100644 index e80812f83c..0000000000 Binary files a/doc/book/src/java-broker/images/3113113.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113114.png b/doc/book/src/java-broker/images/3113114.png deleted file mode 100644 index b237181150..0000000000 Binary files a/doc/book/src/java-broker/images/3113114.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113115.png b/doc/book/src/java-broker/images/3113115.png deleted file mode 100644 index 84ad42b567..0000000000 Binary files a/doc/book/src/java-broker/images/3113115.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113116.png b/doc/book/src/java-broker/images/3113116.png deleted file mode 100644 index 18b979792f..0000000000 Binary files a/doc/book/src/java-broker/images/3113116.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113117.png b/doc/book/src/java-broker/images/3113117.png deleted file mode 100644 index 3b33ef67ac..0000000000 Binary files a/doc/book/src/java-broker/images/3113117.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113118.png b/doc/book/src/java-broker/images/3113118.png deleted file mode 100644 index 60451f88cf..0000000000 Binary files a/doc/book/src/java-broker/images/3113118.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/3113119.png b/doc/book/src/java-broker/images/3113119.png deleted file mode 100644 index 16ded074bd..0000000000 Binary files a/doc/book/src/java-broker/images/3113119.png and /dev/null differ diff --git a/doc/book/src/java-broker/images/HA-BDBHAMessageStore-MBean-jconsole.png b/doc/book/src/java-broker/images/HA-BDBHAMessageStore-MBean-jconsole.png index 6caaacb1e1..29d5494746 100644 Binary files a/doc/book/src/java-broker/images/HA-BDBHAMessageStore-MBean-jconsole.png and b/doc/book/src/java-broker/images/HA-BDBHAMessageStore-MBean-jconsole.png differ diff --git a/doc/book/src/java-broker/images/Management-Web-Console.png b/doc/book/src/java-broker/images/Management-Web-Console.png new file mode 100644 index 0000000000..c752adec3b Binary files /dev/null and b/doc/book/src/java-broker/images/Management-Web-Console.png differ diff --git a/doc/book/src/programming/Programming-In-Apache-Qpid-Book.xml b/doc/book/src/programming/Programming-In-Apache-Qpid-Book.xml deleted file mode 100644 index fd32f42f2e..0000000000 --- a/doc/book/src/programming/Programming-In-Apache-Qpid-Book.xml +++ /dev/null @@ -1,6510 +0,0 @@ - - - - - - - Programming in Apache Qpid - Cross-Platform AMQP Messaging in Java JMS, .NET, C++, and Python - - - Introduction - - Apache Qpid is a reliable, asynchronous messaging system that - supports the AMQP messaging protocol in several common programming - languages. Qpid is supported on most common platforms. - - - - - - On the Java platform, Qpid uses the - established Java JMS - API. - - - - - For Python, C++, and .NET, Qpid defines its own messaging API, the - Qpid Messaging API, which is - conceptually similar in each. - - - On the .NET platform, Qpid also provides a WCF binding. - - - - - Ruby will also use the Qpid Messaging API, which will soon - be implemented. (Ruby currently uses an API that is closely - tied to the AMQP version). - - - - - - - - Using the Qpid Messaging API - - The Qpid Messaging API is quite simple, consisting of only a - handful of core classes. - - - - - - - A message consists of a standard set - of fields (e.g. subject, - reply-to), an application-defined set of - properties, and message content (the main body of the - message). - - - - - - A connection represents a network - connection to a remote endpoint. - - - - - - A session provides a sequentially - ordered context for sending and receiving - messages. A session is obtained from a - connection. - - - - - - A sender sends messages to a target - using the sender.send method. A sender is - obtained from a session for a given target address. - - - - - - A receiver receives messages from a - source using the receiver.fetch method. - A receiver is obtained from a session for a given source - address. - - - - - - - The following sections show how to use these classes in a - simple messaging program. - - -
- A Simple Messaging Program in C++ - - The following C++ program shows how to create a connection, - create a session, send messages using a sender, and receive - messages using a receiver. - - - "Hello world!" in C++ - - #include - #include - #include - #include - - #include ]]> - - using namespace qpid::messaging; - - int main(int argc, char** argv) { - std::string broker = argc > 1 ? argv[1] : "localhost:5672"; - std::string address = argc > 2 ? argv[2] : "amq.topic"; - std::string connectionOptions = argc > 3 ? argv[3] : ""; - - Connection connection(broker, connectionOptions); - try { - connection.open(); - Session session = connection.createSession(); - - Receiver receiver = session.createReceiver(address); - Sender sender = session.createSender(address); - - sender.send(Message("Hello world!")); - - Message message = receiver.fetch(Duration::SECOND * 1); - - session.acknowledge(); - - connection.close(); - return 0; - } catch(const std::exception& error) { - - connection.close(); - return 1; - } - } - - - - Establishes the connection with the messaging broker. - - - Creates a session object on which messages will be sent and received. - - - Creates a receiver that receives messages from the given address. - - - Creates a sender that sends to the given address. - - - Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. - - - Acknowledges receipt of all fetched messages on the - session. This informs the broker that the messages were - transferred and processed by the client successfully. - - - Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. - - - - - -
- -
- A Simple Messaging Program in Python - - The following Python program shows how to create a - connection, create a session, send messages using a sender, and - receive messages using a receiver. - - - "Hello world!" in Python - - - connection = Connection(broker) - - try: - connection.open() - session = connection.session() - - sender = session.sender(address) - receiver = session.receiver(address) - - sender.send(Message("Hello world!")); - - message = receiver.fetch(timeout=1) - print message.content - session.acknowledge() - - except MessagingError,m: - print m - finally: - connection.close() - - - - - Establishes the connection with the messaging broker. - - - Creates a session object on which messages will be sent and received. - - - Creates a receiver that receives messages from the given address. - - - Creates a sender that sends to the given address. - - - Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. - - - Acknowledges receipt of all fetched messages on - the session. This informs the broker that the messages were - transfered and processed by the client successfully. - - - Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. - - - - - -
- - - - -
- A Simple Messaging Program in .NET C# - - The following .NET C# - - - The .NET binding for the Qpid C++ Messaging API - applies to all .NET Framework managed code languages. C# was chosen - for illustration purposes only. - - - program shows how to create a connection, - create a session, send messages using a sender, and receive - messages using a receiver. - - - - "Hello world!" in .NET C# - - using System; - using Org.Apache.Qpid.Messaging; - - namespace Org.Apache.Qpid.Messaging { - class Program { - static void Main(string[] args) { - String broker = args.Length > 0 ? args[0] : "localhost:5672"; - String address = args.Length > 1 ? args[1] : "amq.topic"; - - Connection connection = null; - try { - connection = new Connection(broker); - connection.Open(); - Session session = connection.CreateSession(); - - Receiver receiver = session.CreateReceiver(address); - Sender sender = session.CreateSender(address); - - sender.Send(new Message("Hello world!")); - - Message message = new Message(); - message = receiver.Fetch(DurationConstants.SECOND * 1); - Console.WriteLine("{0}", message.GetContent()); - session.Acknowledge(); - - connection.Close(); - } catch (Exception e) { - Console.WriteLine("Exception {0}.", e); - if (null != connection) - connection.Close(); - } - } - } - } - - - - - - Permits use of Org.Apache.Qpid.Messaging types and methods without explicit namespace qualification. Any .NET project must have a project reference to the assembly file Org.Apache.Qpid.Messaging.dll in order to obtain the definitions of the .NET Binding for Qpid Messaging namespace. - - - Establishes the connection with the messaging broker. - - - Creates a session object on which messages will be sent and received. - - - Creates a receiver that receives messages from the given address. - - - Creates a sender that sends to the given address. - - - Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. - - - Acknowledges receipt of all fetched messages on the - session. This informs the broker that the messages were - transfered and processed by the client successfully. - - - Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. - - - - - -
- - - - - - -
- Addresses - - An address is the name of a message - target or message source. - - In the programs we have just seen, we used - amq.topic as the default address if none is - passed in. This is the name of a standard exchange that always - exists on an AMQP 0-10 messaging broker. - - The methods that create senders and receivers require an - address. The details of sending to a particular target or - receiving from a particular source are then handled by the - sender or receiver. A different target or source can be used - simply by using a different address. - - - An address resolves to a node. The - Qpid Messaging API recognises two kinds of nodes, - queues and topics - - The terms queue and - topic here were chosen to align with - their meaning in JMS. These two addressing 'patterns', - queue and topic, are sometimes refered as point-to-point - and publish-subscribe. AMQP 0-10 has an exchange type - called a topic exchange. When the term - topic occurs alone, it refers to a - Messaging API topic, not the topic - exchange.. - - A queue stores each message until it has been received and - acknowledged, and only one receiver can receive a given message - - There are exceptions to this rule; for instance, - a receiver can use browse mode, which leaves - messages on the queue for other receivers to - read.. - - A topic immediately delivers a message to all eligible - receivers; if there are no eligible receivers, it discards the - message. In the AMQP 0-10 implementation of the API, - - The AMQP 0-10 implementation is the only one - that currently exists. - - queues map to AMQP queues, and topics map to AMQP exchanges. - - In AMQP 0-10, messages are sent to - exchanges, and read from queues. The Messaging API also - allows a sender to send messages to a queue; internally, - Qpid implements this by sending the message to the default - exchange, with the name of the queue as the routing key. The - Messaging API also allows a receiver to receive messages - from a topic; internally, Qpid implements this by setting up - a private subscription queue for the receiver and binding - the subscription queue to the exchange that corresponds to - the topic. - - - In the rest of this tutorial, we present many examples - using two programs that take an address as a command line - parameter. spout sends messages to the - target address, drain receives messages from - the source address. The source code is available in C++, Python, and - .NET C# and can be found in the examples directory for each - language. These programs can use any address string as a source - or a destination, and have many command line options to - configure behavior—use the -h option - for documentation on these options. - - Currently, the C++, Python, and .NET C# - implementations of drain and - spout have slightly different - options. This tutorial uses the C++ implementation. The - options will be reconciled in the near - future. - - - The examples in this tutorial also use the - qpid-config utility to configure AMQP 0-10 - queues and exchanges on a Qpid broker. - - - - - Queues - - Create a queue with qpid-config, send a message using - spout, and read it using drain: - - - $ qpid-config add queue hello-world - $ ./spout hello-world - $ ./drain hello-world - - Message(properties={spout-id:c877e622-d57b-4df2-bf3e-6014c68da0ea:0}, content='') - - - The queue stored the message sent by spout and delivered - it to drain when requested. - - Once the message has been delivered and and acknowledged - by drain, it is no longer available on the queue. If we run - drain one more time, no messages will be retrieved. - - - $ ./drain hello-world - $ - - - - - - Topics - - This example is similar to the previous example, but it - uses a topic instead of a queue. - - First, use qpid-config to remove the queue - and create an exchange with the same name: - - - $ qpid-config del queue hello-world - $ qpid-config add exchange topic hello-world - - - Now run drain and spout the same way we did in the previous example: - - - $ ./spout hello-world - $ ./drain hello-world - $ - - - Topics deliver messages immediately to any interested - receiver, and do not store messages. Because there were no - receivers at the time spout sent the - message, it was simply discarded. When we ran - drain, there were no messages to - receive. - - Now let's run drain first, using the - -t option to specify a timeout in seconds. - While drain is waiting for messages, - run spout in another window. - - First Window: - - - $ ./drain -t 30 hello-word - - - - Second Window: - - - $ ./spout hello-word - - - Once spout has sent a message, return - to the first window to see the output from - drain: - - - Message(properties={spout-id:7da2d27d-93e6-4803-8a61-536d87b8d93f:0}, content='') - - - You can run drain in several separate - windows; each creates a subscription for the exchange, and - each receives all messages sent to the exchange. - - - -
- Address Strings - - So far, our examples have used address strings that - contain only the name of a node. An address - string can also contain a - subject and - options. - - The syntax for an address string is: - - [ / ] [ ; ] - options ::= { : , ... } - ]]> - - Addresses, subjects, and keys are strings. Values can - be numbers, strings (with optional single or double quotes), - maps, or lists. A complete BNF for address strings appears in - . - - - So far, the address strings in this tutorial have only - used simple names. The following sections show how to use - subjects and options. - -
- -
- Subjects - - - Every message has a property called - subject, which is analogous to the - subject on an email message. If no subject is specified, the - message's subject is null. For convenience, address strings - also allow a subject. If a sender's address contains a - subject, it is used as the default subject for the messages - it sends. - - If a receiver's address contains a subject, it is used to - select only messages that match the subject—the matching - algorithm depends on the message source. - - - - In AMQP 0-10, each exchange type has its own matching - algorithm. This is discussed in - . - - - - - Currently, a receiver bound to a queue ignores subjects, - receiving messages from the queue without filtering. Support - for subject filtering on queues will be implemented soon. - - - - - - Using subjects - - In this example we show how subjects affect message - flow. - - First, let's use qpid-config to create a topic exchange. - - - $ qpid-config add exchange topic news-service - - - Now we use drain to receive messages from news-service that match the subject sports. - First Window: - - $ ./drain -t 30 news-service/sports - - - In a second window, let's send messages to news-service using two different subjects: - - Second Window: - - $ ./spout news-service/sports - $ ./spout news-service/news - - - Now look at the first window, the message with the - subject sports has been received, but not - the message with the subject news: - - - Message(properties={qpid.subject:sports, spout-id:9441674e-a157-4780-a78e-f7ccea998291:0}, content='') - - - If you run drain in multiple - windows using the same subject, all instances of - drain receive the messages for that - subject. - - - - The AMQP exchange type we are using here, - amq.topic, can also do more sophisticated - matching. - - A sender's subject can contain multiple words separated by a - . delimiter. For instance, in a news - application, the sender might use subjects like - usa.news, usa.weather, - europe.news, or - europe.weather. - - The receiver's subject can include wildcard characters— - # matches one or more words in the message's - subject, * matches a single word. - - For instance, if the subject in the source address is - *.news, it matches messages with the - subject europe.news or - usa.news; if it is - europe.#, it matches messages with subjects - like europe.news or - europe.pseudo.news. - - - Subjects with multi-word keys - - This example uses drain and spout to demonstrate the - use of subjects with two-word keys. - - Let's use drain with the subject - *.news to listen for messages in which - the second word of the key is - news. - - First Window: - - - $ ./drain -t 30 news-service/*.news - - - Now let's send messages using several different - two-word keys: - - Second Window: - - - $ ./spout news-service/usa.news - $ ./spout news-service/usa.sports - $ ./spout news-service/europe.sports - $ ./spout news-service/europe.news - - - In the first window, the messages with - news in the second word of the key have - been received: - - - Message(properties={qpid.subject:usa.news, spout-id:73fc8058-5af6-407c-9166-b49a9076097a:0}, content='') - Message(properties={qpid.subject:europe.news, spout-id:f72815aa-7be4-4944-99fd-c64c9747a876:0}, content='') - - - - Next, let's use drain with the - subject #.news to match any sequence of - words that ends with news. - - First Window: - - - $ ./drain -t 30 news-service/#.news - - - In the second window, let's send messages using a - variety of different multi-word keys: - - Second Window: - - - $ ./spout news-service/news - $ ./spout news-service/sports - $ ./spout news-service/usa.news - $ ./spout news-service/usa.sports - $ ./spout news-service/usa.faux.news - $ ./spout news-service/usa.faux.sports - - - In the first window, messages with - news in the last word of the key have been - received: - - - Message(properties={qpid.subject:news, spout-id:cbd42b0f-c87b-4088-8206-26d7627c9640:0}, content='') - Message(properties={qpid.subject:usa.news, spout-id:234a78d7-daeb-4826-90e1-1c6540781eac:0}, content='') - Message(properties={qpid.subject:usa.faux.news, spout-id:6029430a-cfcb-4700-8e9b-cbe4a81fca5f:0}, content='') - - - -
- -
- Address String Options - - - The options in an address string can contain additional - information for the senders or receivers created for it, - including: - - - - - Policies for assertions about the node to which an address - refers. - - - For instance, in the address string my-queue; - {assert: always, node:{ type: queue }}, the node - named my-queue must be a queue; if not, - the address does not resolve to a node, and an exception - is raised. - - - - - Policies for automatically creating or deleting the node to which an address refers. - - - For instance, in the address string xoxox ; {create: always}, - the queue xoxox is created, if it does - not exist, before the address is resolved. - - - - - Extension points that can be used for sender/receiver configuration. - - - For instance, if the address for a receiver is - my-queue; {mode: browse}, the receiver - works in browse mode, leaving messages - on the queue so other receivers can receive them. - - - - - Extension points providing more direct control over the underlying protocol. - - - For instance, the x-bindings property - allows greater control over the AMQP 0-10 binding process - when an address is resolved. - - - - - - - Let's use some examples to show how these different kinds of - address string options affect the behavior of senders and - receives. - - -
- assert - - In this section, we use the assert option - to ensure that the address resolves to a node of the required - type. - - - - - Assertions on Nodes - - Let's use qpid-config to create a - queue and a topic. - - - $ qpid-config add queue my-queue - $ qpid-config add exchange topic my-topic - - - - We can now use the address specified to drain to assert that it is - of a particular type: - - - - $ ./drain 'my-queue; {assert: always, node:{ type: queue }}' - $ ./drain 'my-queue; {assert: always, node:{ type: topic }}' - 2010-04-20 17:30:46 warning Exception received from broker: not-found: not-found: Exchange not found: my-queue (../../src/qpid/broker/ExchangeRegistry.cpp:92) [caused by 2 \x07:\x01] - Exchange my-queue does not exist - - - - The first attempt passed without error as my-queue is indeed a - queue. The second attempt however failed; my-queue is not a - topic. - - - - We can do the same thing for my-topic: - - - - $ ./drain 'my-topic; {assert: always, node:{ type: topic }}' - $ ./drain 'my-topic; {assert: always, node:{ type: queue }}' - 2010-04-20 17:31:01 warning Exception received from broker: not-found: not-found: Queue not found: my-topic (../../src/qpid/broker/SessionAdapter.cpp:754) [caused by 1 \x08:\x01] - Queue my-topic does not exist - - - - Now let's use the create option to - create the queue xoxox if it does not already - exist: - -
- -
- create - - In previous examples, we created the queue before - listening for messages on it. Using create: - always, the queue is automatically created if it - does not exist. - - - Creating a Queue Automatically - - First Window: - $ ./drain -t 30 "xoxox ; {create: always}" - - - Now we can send messages to this queue: - - Second Window: - $ ./spout "xoxox ; {create: always}" - - Returning to the first window, we see that drain has received this message: - - Message(properties={spout-id:1a1a3842-1a8b-4f88-8940-b4096e615a7d:0}, content='') - - The details of the node thus created can be controlled by further options within the node. See for details. -
- -
- browse - Some options specify message transfer semantics; for - instance, they may state whether messages should be consumed or - read in browsing mode, or specify reliability - characteristics. The following example uses the - browse option to receive messages without - removing them from a queue. - - - Browsing a Queue - - Let's use the browse mode to receive messages without - removing them from the queue. First we send three messages to the - queue: - - - $ ./spout my-queue --content one - $ ./spout my-queue --content two - $ ./spout my-queue --content three - - - Now we use drain to get those messages, using the browse option: - - $ ./drain 'my-queue; {mode: browse}' - Message(properties={spout-id:fbb93f30-0e82-4b6d-8c1d-be60eb132530:0}, content='one') - Message(properties={spout-id:ab9e7c31-19b0-4455-8976-34abe83edc5f:0}, content='two') - Message(properties={spout-id:ea75d64d-ea37-47f9-96a9-d38e01c97925:0}, content='three') - - - We can confirm the messages are still on the queue by repeating the drain: - - $ ./drain 'my-queue; {mode: browse}' - Message(properties={spout-id:fbb93f30-0e82-4b6d-8c1d-be60eb132530:0}, content='one') - Message(properties={spout-id:ab9e7c31-19b0-4455-8976-34abe83edc5f:0}, content='two') - Message(properties={spout-id:ea75d64d-ea37-47f9-96a9-d38e01c97925:0}, content='three') - - -
- -
- x-bindings - - Greater control over the AMQP 0-10 binding process can - be achieved by including an x-bindings - option in an address string. - - For instance, the XML Exchange is an AMQP 0-10 custom exchange - provided by the Apache Qpid C++ broker. It allows messages to - be filtered using XQuery; queries can address either message - properties or XML content in the body of the message. The - xquery is specified in the arguments field of the AMQP 0-10 - command. When using the messaging API an xquery can be - specified in and address that resolves to an XML exchange by - using the x-bindings property. - - - An instance of the XML Exchange must be added before it - can be used: - - - $ qpid-config add exchange xml xml - - - When using the XML Exchange, a receiver provides an - XQuery as an x-binding argument. If the query contains a - context item (a path starting with .), then it - is applied to the content of the message, which must be - well-formed XML. For instance, ./weather is - a valid XQuery, which matches any message in which the root - element is named weather. Here is an - address string that contains this query: - - - - When using longer queries with drain, - it is often useful to place the query in a file, and use - cat in the command line. We do this in the - following example. - - - Using the XML Exchange - - This example uses an x-binding that contains queries, which filter based on the content of XML messages. Here is an XQuery that we will use in this example: - - - 50 - and $w/temperature_f - $w/dewpoint > 5 - and $w/wind_speed_mph > 7 - and $w/wind_speed_mph < 20 ]]> - - - We can specify this query in an x-binding to listen to messages that meet the criteria specified by the query: - - First Window: - - - $ ./drain -f "xml; {link:{x-bindings:[{key:'weather', - arguments:{xquery:\"$(cat rdu.xquery )\"}}]}}" - - - In another window, let's create an XML message that meets the criteria in the query, and place it in the file rdu.xml: - - - - Raleigh-Durham International Airport (KRDU) - 16 - 70 - 35 - - ]]> - - Now let's use spout to send this message to the XML exchange: - - Second Window: - - spout --content "$(cat rdu.xml)" xml/weather - - - Returning to the first window, we see that the message has been received: - - - Raleigh-Durham International Airport (KRDU) - 16 - 40 - 35 - ') ]]> - - -
- - - - - -
- Address String Options - Reference - - - Address String Options - - - - - - - option - value - semantics - - - - - - assert - - - one of: always, never, sender or receiver - - - Asserts that the properties specified in the node option - match whatever the address resolves to. If they do not, - resolution fails and an exception is raised. - - - - - - create - - - one of: always, never, sender or receiver - - - Creates the node to which an address refers if it does - not exist. No error is raised if the node does - exist. The details of the node may be specified in the - node option. - - - - - delete - - - one of: always, never, sender or receiver - - - Delete the node when the sender or receiver is closed. - - - - - node - - - A nested map containing the entries shown in . - - - Specifies properties of the node to which the address - refers. These are used in conjunction with the assert or - create options. - - - - - link - - - A nested map containing the entries shown in . - - - Used to control the establishment of a conceptual link - from the client application to or from the target/source - address. - - - - - mode - - - one of: browse, consume - - - This option is only of relevance for source addresses - that resolve to a queue. If browse is specified the - messages delivered to the receiver are left on the queue - rather than being removed. If consume is specified the - normal behaviour applies; messages are removed from the - queue once the client acknowledges their receipt. - - - - -
- - - - Node Properties - - - - - - - property - value - semantics - - - - - - type - - - topic, queue - - - Indicates the type of the node. - - - - - durable - - - True, False - - - Indicates whether the node survives a loss of - volatile storage e.g. if the broker is restarted. - - - - - x-declare - - - A nested map whose values correspond to the valid fields - on an AMQP 0-10 queue-declare or exchange-declare - command. - - - These values are used to fine tune the creation or - assertion process. Note however that they are protocol - specific. - - - - - x-bindings - - - A nested list in which each binding is represented by - a map. The entries of the map for a binding contain - the fields that describe an AMQP 0-10 binding. Here is - the format for x-bindings: - - , - queue: , - key: , - arguments: { - : , - ..., - : } - }, - ... - ] - ]]> - - - In conjunction with the create option, each of these - bindings is established as the address is resolved. In - conjunction with the assert option, the existence of - each of these bindings is verified during - resolution. Again, these are protocol specific. - - - - -
- - - Link Properties - - - - - - - option - value - semantics - - - - - - reliability - - - one of: unreliable, at-least-once, at-most-once, exactly-once - - - Reliability indicates the level of reliability that - the sender or receiver. unreliable - and at-most-once are currently - treated as synonyms, and allow messages to be lost if - a broker crashes or the connection to a broker is - lost. at-least-once guarantees that - a message is not lost, but duplicates may be - received. exactly-once guarantees - that a message is not lost, and is delivered precisely - once. Currently only unreliable - and at-least-once are supported. - If at-most-once is requested, - unreliable will be used and for durable messages on - durable queues there is the possibility that messages - will be redelivered; if exactly-once is requested, - at-least-once will be used and the application needs to - be able to deal with duplicates. - - - - - durable - - - True, False - - - Indicates whether the link survives a loss of - volatile storage e.g. if the broker is restarted. - - - - - x-declare - - - A nested map whose values correspond to the valid fields - of an AMQP 0-10 queue-declare command. - - - These values can be used to customise the subscription - queue in the case of receiving from an exchange. Note - however that they are protocol specific. - - - - - x-subscribe - - - A nested map whose values correspond to the valid fields - of an AMQP 0-10 message-subscribe command. - - - These values can be used to customise the subscription. - - - - - x-bindings - - - A nested list each of whose entries is a map that may - contain fields (queue, exchange, key and arguments) - describing an AMQP 0-10 binding. - - - These bindings are established during resolution - independent of the create option. They are considered - logically part of the linking process rather than of - node creation. - - - - - - -
-
- -
- Address String Grammar - - This section provides a formal grammar for address strings. - - - Tokens - The following regular expressions define the tokens used - to parse address strings: - - - - Grammar - The formal grammar for addresses is given below: - - - - - - - Address String Options - The address string options map supports the following parameters: - - - [ / ] ; { - create: always | sender | receiver | never, - delete: always | sender | receiver | never, - assert: always | sender | receiver | never, - mode: browse | consume, - node: { - type: queue | topic, - durable: True | False, - x-declare: { ... ... }, - x-bindings: [, ... ] - }, - link: { - name: , - durable: True | False, - reliability: unreliable | at-most-once | at-least-once | exactly-once, - x-declare: { ... ... }, - x-bindings: [, ... ], - x-subscribe: { ... ... } - } - } - ]]> - - - - Create, Delete, and Assert Policies - The create, delete, and assert policies specify who should - perfom the associated action: - always: the action is performed by any messaging client - sender: the action is only performed by a sender - receiver: the action is only performed by a receiver - never: the action is never performed (this is the default) - - - - Node-Type - The node-type is one of: - topic: in the AMQP 0-10 - mapping, a topic node defaults to the topic exchange, x-declare - may be used to specify other exchange types - queue: this is the default node-type - -
- - -
- -
- Sender Capacity and Replay - - The send method of a sender has an optional second parameter - that controls whether the send call is synchronous or not. A - synchronous send call will block until the broker has confirmed - receipt of the message. An asynchronous send call will return - before the broker confirms receipt of the message, allowing for - example further send calls to be made without waiting for a - roundtrip to the broker for each message. This is desirable where - increased throughput is important. - - The sender maintains a list of sent messages whose receipt - has yet to be confirmed by the broker. The maximum number of such - messages that it will hold is defined by the capacity of the - sender, which can be set by the application. If an application - tries to send with a sender whose capacity is already fully used - up, the send call will block waiting for capacity regardless of - the value of the sync flag. - - The sender can be queried for the available space (i.e. the - unused capacity), and for the current count of unsettled messages - (i.e. those held in the replay list pending confirmation by the - server). When the unsettled count is zero, all messages on that - sender have been successfully sent. - - If the connection fails and is transparently reconnected - (see for details on how to control - this feature), the unsettled messages for each sender over that - connection will be re-transmitted. This provides a transparent - level of reliability. This feature can be controlled through the - link's reliability as defined in the address (see - ). At present only - at-least-once guarantees are offered. -
- -
- Receiver Capacity (Prefetch) - - By default, a receiver requests the next message from the - server in response to each fetch call, resulting in messages being - sent to the receiver one at a time. As in the case of sending, it - is often desirable to avoid this roundtrip for each message. This - can be achieved by allowing the receiver - to prefetch messages in anticipation of - fetch calls being made. The receiver needs to be able to store - these prefetched messages, the number it can hold is controlled by - the receivers capacity. - -
- -
- Acknowledging Received Messages - - Applications that receive messages should acknowledge their - receipt by calling the session's acknowledge method. As in the - case of sending messages, acknowledged transfer of messages to - receivers provides at-least-once reliability, which means that the - loss of the connection or a client crash does not result in lost - messages; durable messages are not lost even if the broker is - restarted. - - Some cases may not require this however and the reliability can be - controlled through a link property in the address options (see - ). - - The acknowledge call acknowledges all messages received on - the session (i.e. all message that have been returned from a fetch - call on a receiver created on that session). - - The acknowledge call also support an optional parameter - controlling whether the call is synchronous or not. A synchronous - acknowledge will block until the server has confirmed that it has - received the acknowledgement. In the asynchronous case, when the - call returns there is not yet any guarantee that the server has - received and processed the acknowledgement. The session may be - queried for the number of unsettled acknowledgements; when that - count is zero all acknowledgements made for received messages have - been successful. - -
- - -
- Receiving Messages from Multiple Sources - - A receiver can only read from one source, but many - programs need to be able to read messages from many sources. In - the Qpid Messaging API, a program can ask a session for - the next receiver; that is, the receiver that is - responsible for the next available message. The following - examples show how this is done in C++, Python, and .NET C#. - - - Note that to use this pattern you must enable prefetching - for each receiver of interest so that the broker will send - messages before a fetch call is made. See - for more on this. - - - Receiving Messages from Multiple Sources - - C++: - - - - Python: - - - .NET C#: - - - -
- -
- Transactions - - Sometimes it is useful to be able to group messages - transfers - sent and/or received - on a session into atomic - grouping. This can be done be creating the session as - transactional. On a transactional session sent messages only - become available at the target address on commit. Likewise any - received and acknowledged messages are only discarded at their - source on commit - - Note that this currently is only true for - messages received using a reliable mode - e.g. at-least-once. Messages sent by a broker to a receiver in - unreliable receiver will be discarded immediately regardless of - transctionality. - - . - - - Transactions - C++: - - - .NET C#: - - - - Connection connection = new Connection(broker); - Session session = connection.CreateTransactionalSession(); - ... - if (smellsOk()) - session.Commit(); - else - session.Rollback(); - - - - -
- -
- Connection Options - - - Aspects of the connections behaviour can be controlled through - specifying connection options. For example, connections can be - configured to automatically reconnect if the connection to a - broker is lost. - - - - Specifying Connection Options in C++, Python, and .NET - - In C++, these options can be set using Connection::setOption() or by passing in a set of options to the constructor. The options can be passed in as a map or in string form: - - - - or - - - - In Python, these options can be set as attributes of the connection or using named arguments in - the Connection constructor: - - - - or - - - - In .NET, these options can be set using Connection.SetOption() or by passing in a set of options to the constructor. The options can be passed in as a map or in string form: - - - - Connection connection= new Connection("localhost:5672", "{reconnect: true}"); - try { - connection.Open(); - !!! SNIP !!! - - - or - - - - Connection connection = new Connection("localhost:5672"); - connection.SetOption("reconnect", true); - try { - connection.Open(); - !!! SNIP !!! - - - See the reference documentation for details in each language. - - - The following table lists the supported connection options. - - - Connection Options - - - - - - - option name - value type - semantics - - - - - - - username - - - string - - - The username to use when authenticating to the broker. - - - - - password - - - string - - - The password to use when authenticating to the broker. - - - - - sasl_mechanisms - - - string - - - The specific SASL mechanisms to use with the python - client when authenticating to the broker. The value - is a space separated list. - - - - - - - reconnect - - - boolean - - - Transparently reconnect if the connection is lost. - - - - - reconnect_timeout - - - integer - - - Total number of seconds to continue reconnection attempts before giving up and raising an exception. - - - - - reconnect_limit - - - integer - - - Maximum number of reconnection attempts before giving up and raising an exception. - - - - - reconnect_interval_min - - - integer representing time in seconds - - - Minimum number of seconds between reconnection attempts. The first reconnection attempt is made immediately; if that fails, the first reconnection delay is set to the value of reconnect_interval_min; if that attempt fails, the reconnect interval increases exponentially until a reconnection attempt succeeds or reconnect_interval_max is reached. - - - - - reconnect_interval_max - - - integer representing time in seconds - - - Maximum reconnect interval. - - - - - reconnect_interval - - - integer representing time in seconds - - - Sets both reconnection_interval_min and reconnection_interval_max to the same value. - - - - - - heartbeat - - - integer representing time in seconds - - - Requests that heartbeats be sent every N seconds. If two - successive heartbeats are missed the connection is - considered to be lost. - - - - - protocol - - - string - - - Sets the underlying protocol used. The default option is 'tcp'. To enable ssl, set to 'ssl'. The C++ client additionally supports 'rdma'. - - - - - tcp-nodelay - - - boolean - - - Set tcp no-delay, i.e. disable Nagle algorithm. [C++ only] - - - - -
- -
- -
- Maps and Lists in Message Content - - Many messaging applications need to exchange data across - languages and platforms, using the native datatypes of each - programming language. - - The Qpid Messaging API supports map and list in message content. - - Unlike JMS, there is not a specific message type for - map messages. - - - - Note that the Qpid JMS client supports MapMessages whose values can be nested maps or lists. This is not standard JMS behaviour. - - - Specific language support for map and list objects are shown in the following table. - - - Map and List Representation in Supported Languages - - - - Language - map - list - - - - - Python - dict - list - - - C++ - Variant::Map - Variant::List - - - Java - MapMessage -   - - - .NET - Dictionary<string, object> - Collection<object> - - - -
- - In all languages, messages are encoded using AMQP's portable datatypes. - - - - Because of the differences in type systems among - languages, the simplest way to provide portable messages is to - rely on maps, lists, strings, 64 bit signed integers, and - doubles for messages that need to be exchanged across languages - and platforms. - - -
- Qpid Maps and Lists in Python - - In Python, Qpid supports the dict and list types directly in message content. The following code shows how to send these structures in a message: - - - Sending Qpid Maps and Lists in Python - - - - - The following table shows the datatypes that can be sent in a Python map message, - and the corresponding datatypes that will be received by clients in Java or C++. - - - - Python Datatypes in Maps - - - - Python Datatype - → C++ - → Java - - - - boolboolboolean - intint64long - longint64long - floatdoubledouble - unicodestringjava.lang.String - uuidqpid::types::Uuidjava.util.UUID - dictVariant::Mapjava.util.Map - listVariant::Listjava.util.List - - -
- -
- - - - -
- Qpid Maps and Lists in C++ - - - In C++, Qpid defines the the - Variant::Map and - Variant::List types, which can be - encoded into message content. The following code shows how to - send these structures in a message: - - - Sending Qpid Maps and Lists in C++ - - - - The following table shows the datatypes that can be sent - in a C++ map message, and the corresponding datatypes that - will be received by clients in Java and Python. - - - C++ Datatypes in Maps - - - - C++ Datatype - → Python - → Java - - - - boolboolboolean - uint16int | longshort - uint32int | longint - uint64int | longlong - int16int | longshort - int32int | longint - int64int | longlong - floatfloatfloat - doublefloatdouble - stringunicodejava.lang.String - qpid::types::Uuiduuidjava.util.UUID - Variant::Mapdictjava.util.Map - Variant::Listlistjava.util.List - - -
-
- -
- Qpid Maps and Lists in .NET - - - - The .NET binding for the Qpid Messaging API binds .NET managed data types - to C++ Variant data types. The following code shows how to - send Map and List structures in a message: - - - - - Sending Qpid Maps and Lists in .NET C# - content = new Dictionary(); - Dictionary subMap = new Dictionary(); - Collection colors = new Collection(); - - // add simple types - content["id"] = 987654321; - content["name"] = "Widget"; - content["percent"] = 0.99; - - // add nested amqp/map - subMap["name"] = "Smith"; - subMap["number"] = 354; - content["nestedMap"] = subMap; - - // add an amqp/list - colors.Add("red"); - colors.Add("green"); - colors.Add("white"); - content["colorsList"] = colors; - - // add one of each supported amqp data type - bool mybool = true; - content["mybool"] = mybool; - - byte mybyte = 4; - content["mybyte"] = mybyte; - - UInt16 myUInt16 = 5; - content["myUInt16"] = myUInt16; - - UInt32 myUInt32 = 6; - content["myUInt32"] = myUInt32; - - UInt64 myUInt64 = 7; - content["myUInt64"] = myUInt64; - - char mychar = 'h'; - content["mychar"] = mychar; - - Int16 myInt16 = 9; - content["myInt16"] = myInt16; - - Int32 myInt32 = 10; - content["myInt32"] = myInt32; - - Int64 myInt64 = 11; - content["myInt64"] = myInt64; - - Single mySingle = (Single)12.12; - content["mySingle"] = mySingle; - - Double myDouble = 13.13; - content["myDouble"] = myDouble; - - Guid myGuid = new Guid("000102030405060708090a0b0c0d0e0f"); - content["myGuid"] = myGuid; - - Message message = new Message(content); - Send(message, true); - ]]> - - - - The following table shows the mapping between datatypes in .NET and C++. - - - - Datatype Mapping between C++ and .NET binding - - - - C++ Datatype - → .NET binding - - - - voidnullptr - boolbool - uint8byte - uint16UInt16 - uint32UInt32 - uint64UInt64 - uint8char - int16Int16 - int32Int32 - int64Int64 - floatSingle - doubleDouble - stringstring - - Strings are currently interpreted only with UTF-8 encoding. - - qpid::types::UuidGuid - Variant::Map]]> - - Variant::List]]> - - - -
- - - - - - - -
- The Request / Response Pattern - Request / Response applications use the reply-to property, - described in , to allow a server - to respond to the client that sent a message. A server sets up a - service queue, with a name known to clients. A client creates a - private queue for the server's response, creates a message for a - request, sets the request's reply-to property to the address of - the client's response queue, and sends the request to the - service queue. The server sends the response to the address - specified in the request's reply-to property. - - - Request / Response Applications in C++ - - This example shows the C++ code for a client and server - that use the request / response pattern. - - The server creates a service queue and waits for a - message to arrive. If it receives a message, it sends a - message back to the sender. - - - - The client creates a sender for the service queue, and - also creates a response queue that is deleted when the - client closes the receiver for the response queue. In the C++ - client, if the address starts with the character - #, it is given a unique name. - - " << response.getContent() << std::endl; - ]]> - - The client sends the string ping to - the server. The server sends the response - pong back to the same client, using the - replyTo property. - - - -
- - -
- Performance Tips - - - - Consider prefetching messages for receivers (see - ). This helps eliminate roundtrips - and increases throughput. Prefetch is disabled by default, - and enabling it is the most effective means of improving - throughput of received messages. - - - Send messages asynchronously. Again, this helps - eliminate roundtrips and increases throughput. The C++ and - .NET clients send asynchronously by default, however the - python client defaults to synchronous sends. - - - Acknowledge messages in batches (see - ). Rather than - acknowledging each message individually, consider issuing - acknowledgements after n messages and/or after a particular - duration has elapsed. - - - Tune the sender capacity (see - ). If the capacity is too low the - sender may block waiting for the broker to confirm receipt - of messages, before it can free up more capacity. - - - If you are setting a reply-to address on messages - being sent by the c++ client, make sure the address type is - set to either queue or topic as appropriate. This avoids the - client having to determine which type of node is being - refered to, which is required when hanling reply-to in AMQP - 0-10. - - - For latency sensitive applications, setting tcp-nodelay - on qpidd and on client connections can help reduce the - latency. - - -
- -
- Cluster Failover - - The messaging broker can be run in clustering mode, which provides high reliability through replicating state between brokers in the cluster. If one broker in a cluster fails, clients can choose another broker in the cluster and continue their work. Each broker in the cluster also advertises the addresses of all known brokers - - This is done via the amq.failover exchange in AMQP 0-10 - - . A client can use this information to dynamically keep the list of reconnection urls up to date. - - In C++, the FailoverUpdates class provides this functionality: - - - Tracking cluster membership - - In C++: - - - ... - Connection connection("localhost:5672"); - connection.setOption("reconnect", true); - try { - connection.open(); - std::auto_ptr updates(new FailoverUpdates(connection)); - ]]> - - - In python: - - - - - In .NET C#: - - - - using Org.Apache.Qpid.Messaging; - ... - connection = new Connection("localhost:5672"); - connection.SetOption("reconnect", true); - try { - connection.Open(); - FailoverUpdates failover = new FailoverUpdates(connection); - - - - - -
- - - -
- Logging - - To simplify debugging, Qpid provides a logging facility - that prints out messaging events. - -
- Logging in C++ - - The Qpidd broker and C++ clients can both use environment variables to enable logging. Linux and Windows systems use the same named environment variables and values. - - Use QPID_LOG_ENABLE to set the level of logging you are interested in (trace, debug, info, notice, warning, error, or critical): - - - - export QPID_LOG_ENABLE="warning+" - - - The Qpidd broker and C++ clients use QPID_LOG_OUTPUT to determine where logging output should be sent. This is either a file name or the special values stderr, stdout, or syslog: - - - - export QPID_LOG_TO_FILE="/tmp/myclient.out" - - - - From a Windows command prompt, use the following command format to set the environment variables: - - - - set QPID_LOG_ENABLE=warning+ - set QPID_LOG_TO_FILE=D:\tmp\myclient.out - -
- -
- Logging in Python - - The Python client library supports logging using the standard Python logging module. The easiest way to do logging is to use the basicConfig(), which reports all warnings and errors: - - - from logging import basicConfig - basicConfig() - - - Qpidd also provides a convenience method that makes it easy to specify the level of logging desired. For instance, the following code enables logging at the DEBUG level: - - - from qpid.log import enable, DEBUG - enable("qpid.messaging.io", DEBUG) - - - For more information on Python logging, see http://docs.python.org/lib/node425.html. For more information on Qpid logging, use $ pydoc qpid.log. - -
-
- - - -
- The AMQP 0-10 mapping - - - This section describes the AMQP 0-10 mapping for the Qpid - Messaging API. - - - The interaction with the broker triggered by creating a sender - or receiver depends on what the specified address resolves - to. Where the node type is not specified in the address, the - client queries the broker to determine whether it refers to a - queue or an exchange. - - - When sending to a queue, the queue's name is set as the - routing key and the message is transfered to the default (or - nameless) exchange. When sending to an exchange, the message - is transfered to that exchange and the routing key is set to - the message subject if one is specified. A default subject may - be specified in the target address. The subject may also be - set on each message individually to override the default if - required. In each case any specified subject is also added as - a qpid.subject entry in the application-headers field of the - message-properties. - - - When receiving from a queue, any subject in the source address - is currently ignored. The client sends a message-subscribe - request for the queue in question. The accept-mode is - determined by the reliability option in the link properties; - for unreliable links the accept-mode is none, for reliable - links it is explicit. The default for a queue is reliable. The - acquire-mode is determined by the value of the mode option. If - the mode is set to browse the acquire mode is not-acquired, - otherwise it is set to pre-acquired. The exclusive and - arguments fields in the message-subscribe command can be - controlled using the x-subscribe map. - - - When receiving from an exchange, the client creates a - subscription queue and binds that to the exchange. The - subscription queue's arguments can be specified using the - x-declare map within the link properties. The reliability - option determines most of the other parameters. If the - reliability is set to unreliable then an auto-deleted, - exclusive queue is used meaning that if the client or - connection fails messages may be lost. For exactly-once the - queue is not set to be auto-deleted. The durability of the - subscription queue is determined by the durable option in the - link properties. The binding process depends on the type of - the exchange the source address resolves to. - - - - - - For a topic exchange, if no subject is specified and no - x-bindings are defined for the link, the subscription - queue is bound using a wildcard matching any routing key - (thus satisfying the expectation that any message sent to - that address will be received from it). If a subject is - specified in the source address however, it is used for - the binding key (this means that the subject in the source - address may be a binding pattern including wildcards). - - - - - For a fanout exchange the binding key is irrelevant to - matching. A receiver created from a source address that - resolves to a fanout exchange receives all messages - sent to that exchange regardless of any subject the source - address may contain. An x-bindings element in the link - properties should be used if there is any need to set the - arguments to the bind. - - - - - For a direct exchange, the subject is used as the binding - key. If no subject is specified an empty string is used as - the binding key. - - - - - For a headers exchange, if no subject is specified the - binding arguments simply contain an x-match entry and no - other entries, causing all messages to match. If a subject - is specified then the binding arguments contain an x-match - entry set to all and an entry for qpid.subject whose value - is the subject in the source address (this means the - subject in the source address must match the message - subject exactly). For more control the x-bindings element - in the link properties must be used. - - - - - For the XML exchange,Note that the XML - exchange is not a standard AMQP exchange type. It is a - Qpid extension and is currently only supported by the C++ - broker. if a subject is specified it is - used as the binding key and an XQuery is defined that - matches any message with that value for - qpid.subject. Again this means that only messages whose - subject exactly match that specified in the source address - are received. If no subject is specified then the empty - string is used as the binding key with an xquery that will - match any message (this means that only messages with an - empty string as the routing key will be received). For more - control the x-bindings element in the link properties must - be used. A source address that resolves to the XML - exchange must contain either a subject or an x-bindings - element in the link properties as there is no way at - present to receive any message regardless of routing key. - - - - - - If an x-bindings list is present in the link options a binding - is created for each element within that list. Each element is - a nested map that may contain values named queue, exchange, - key or arguments. If the queue value is absent the queue name - the address resolves to is implied. If the exchange value is - absent the exchange name the address resolves to is implied. - - - The following table shows how Qpid Messaging API message - properties are mapped to AMQP 0-10 message properties and - delivery properties. In this table msg - refers to the Message class defined in the Qpid Messaging API, - mp refers to an AMQP 0-10 - message-properties struct, and - dp refers to an AMQP 0-10 - delivery-properties struct. - - - Mapping to AMQP 0-10 Message Properties - - - - - - - Python API - C++ API - - - The .NET Binding for C++ Messaging provides all the - message and delivery properties described in the C++ API. - See . - - - - AMQP 0-10 PropertyIn these entries, mp refers to an AMQP message property, and dp refers to an AMQP delivery property. - - - - - msg.idmsg.{get,set}MessageId()mp.message_id - - - msg.subjectmsg.{get,set}Subject()mp.application_headers["qpid.subject"] - - - msg.user_idmsg.{get,set}UserId()mp.user_id - - - msg.reply_tomsg.{get,set}ReplyTo()mp.reply_toThe reply_to is converted from the protocol representation into an address. - - - msg.correlation_idmsg.{get,set}CorrelationId()mp.correlation_id - - - msg.durablemsg.{get,set}Durable()dp.delivery_mode == delivery_mode.persistentNote that msg.durable is a boolean, not an enum. - - - msg.prioritymsg.{get,set}Priority()dp.priority - - - msg.ttlmsg.{get,set}Ttl()dp.ttl - - - msg.redeliveredmsg.{get,set}Redelivered()dp.redelivered - - msg.propertiesmsg.getProperties()/msg.setProperty()mp.application_headers - - - msg.content_typemsg.{get,set}ContentType()mp.content_type - - - -
- -
- 0-10 Message Property Keys - - The QPID Messaging API also recognises special message property keys and - automatically provides a mapping to their corresponding AMQP 0-10 definitions. - - - - - When sending a message, if the properties contain an entry for - x-amqp-0-10.app-id, its value will be used to set the - message-properties.app-id property in the outgoing - message. Likewise, if an incoming message has - message-properties.app-id set, its value can be accessed - via the x-amqp-0-10.app-id message property key. - - - - - When sending a message, if the properties contain an entry for - x-amqp-0-10.content-encoding, its value will be used to - set the message-properties.content-encoding property in - the outgoing message. Likewise, if an incoming message has - message-properties.content-encoding set, its value can be - accessed via the x-amqp-0-10.content-encoding message - property key. - - - - - The routing key (delivery-properties.routing-key) in an - incoming messages can be accessed via the - x-amqp-0-10.routing-key message property. - - - - - If the timestamp delivery property is set in an incoming message - (delivery-properties.timestamp), the timestamp value will - be made available via the x-amqp-0-10.timestamp message - property. - - - This special property is currently not supported by the Qpid JMS client. - - - - - - - Accessing the AMQP 0-10 Message Timestamp in Python - - The following code fragment checks for and extracts the message timestamp from - a received message. - - - try: - msg = receiver.fetch(timeout=1) - if "x-amqp-0-10.timestamp" in msg.properties: - print("Timestamp=%s" % str(msg.properties["x-amqp-0-10.timestamp"])) - except Empty: - pass - - - - Accessing the AMQP 0-10 Message Timestamp in C++ - - The same example, except in C++. - - - messaging::Message msg; - if (receiver.fetch(msg, messaging::Duration::SECOND*1)) { - if (msg.getProperties().find("x-amqp-0-10.timestamp") != msg.getProperties().end()) { - - } - } - - -
-
- - - - - - - - Using the Qpid JMS client -
- A Simple Messaging Program in Java JMS - - The following program shows how to send and receive a - message using the Qpid JMS client. JMS programs typically use - JNDI to obtain connection factory and destination objects which - the application needs. In this way the configuration is kept - separate from the application code itself. - - In this example, we create a JNDI context using a - properties file, use the context to lookup a connection factory, - create and start a connection, create a session, and lookup a - destination from the JNDI context. Then we create a producer and - a consumer, send a message with the producer and receive it with - the consumer. This code should be straightforward for anyone - familiar with Java JMS. - - - "Hello world!" in Java - - package org.apache.qpid.example.jmsexample.hello; - - import javax.jms.*; - import javax.naming.Context; - import javax.naming.InitialContext; - import java.util.Properties; - - public class Hello { - - public Hello() { - } - - public static void main(String[] args) { - Hello producer = new Hello(); - producer.runTest(); - } - - private void runTest() { - try { - Properties properties = new Properties(); - properties.load(this.getClass().getResourceAsStream("hello.properties")); - Context context = new InitialContext(properties); - - ConnectionFactory connectionFactory - = (ConnectionFactory) context.lookup("qpidConnectionfactory"); - Connection connection = connectionFactory.createConnection(); - connection.start(); - - Session session=connection.createSession(false,Session.AUTO_ACKNOWLEDGE); - Destination destination = (Destination) context.lookup("topicExchange"); - - MessageProducer messageProducer = session.createProducer(destination); - MessageConsumer messageConsumer = session.createConsumer(destination); - - TextMessage message = session.createTextMessage("Hello world!"); - messageProducer.send(message); - - message = (TextMessage)messageConsumer.receive(); - System.out.println(message.getText()); - - connection.close(); - context.close(); - } - catch (Exception exp) { - exp.printStackTrace(); - } - } - } - - - - - - Loads the JNDI properties file, which specifies connection properties, queues, topics, and addressing options. See for details. - - - Creates the JNDI initial context. - - - Creates a JMS connection factory for Qpid. - - - Creates a JMS connection. - - - Activates the connection. - - - Creates a session. This session is not transactional (transactions='false'), and messages are automatically acknowledged. - - - Creates a destination for the topic exchange, so senders and receivers can use it. - - - Creates a producer that sends messages to the topic exchange. - - - Creates a consumer that reads messages from the topic exchange. - - - Reads the next available message. - - - Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. - - - Closes the JNDI context. - - - - The contents of the hello.properties file are shown below. - - - JNDI Properties File for "Hello world!" example - - java.naming.factory.initial - = org.apache.qpid.jndi.PropertiesFileInitialContextFactory - - # connectionfactory.[jndiname] = [ConnectionURL] - connectionfactory.qpidConnectionfactory - = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672' - # destination.[jndiname] = [address_string] - destination.topicExchange = amq.topic - - - - - - Defines a connection factory from which connections - can be created. The syntax of a ConnectionURL is given in - . - - - Defines a destination for which MessageProducers - and/or MessageConsumers can be created to send and receive - messages. The value for the destination in the properties - file is an address string as described in - . In the JMS - implementation MessageProducers are analogous to senders in - the Qpid Message API, and MessageConsumers are analogous to - receivers. - - - -
- -
- Apache Qpid JNDI Properties for AMQP Messaging - - - - Apache Qpid defines JNDI properties that can be used to specify JMS Connections and Destinations. Here is a typical JNDI properties file: - - - - JNDI Properties File - - - - The following sections describe the JNDI properties that Qpid uses. - - -
- JNDI Properties for Apache Qpid - - Apache Qpid supports the properties shown in the following table: - - - JNDI Properties supported by Apache Qpid - - - - - Property - - - Purpose - - - - - - - connectionfactory.<jndiname> - - - - The Connection URL that the connection factory uses to perform connections. - - - - - - queue.<jndiname> - - - - A JMS queue, which is implemented as an amq.direct exchange in Apache Qpid. - - - - - - topic.<jndiname> - - - - A JMS topic, which is implemented as an amq.topic exchange in Apache Qpid. - - - - - - destination.<jndiname> - - - - Can be used for defining all amq destinations, - queues, topics and header matching, using an - address string. - - Binding URLs, which were used in - earlier versions of the Qpid Java JMS client, can - still be used instead of address - strings. - - - - - -
-
- -
- Connection URLs - - In JNDI properties, a Connection URL specifies properties for a connection. The format for a Connection URL is: - - - amqp://[<user>:<pass>@][<clientid>]<virtualhost>[?<option>='<value>'[&<option>='<value>']] - - - For instance, the following Connection URL specifies a user name, a password, a client ID, a virtual host ("test"), a broker list with a single broker, and a TCP host with the host name localhost using port 5672: - - - amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672' - - - Apache Qpid supports the following properties in Connection URLs: - - - Connection URL Properties - - - - - Option - - - Type - - - Description - - - - - - - brokerlist - - - see below - - - List of one or more broker addresses. - - - - - maxprefetch - - - integer - - - - The maximum number of pre-fetched messages per consumer. If not specified, default value of 500 is used. - - - Note: You can also set the default per-consumer prefetch value on a client-wide basis by configuring the client using Java system properties. - - - - - - sync_publish - - - {'persistent' | 'all'} - - - A sync command is sent after every persistent message to guarantee that it has been received; if the value is 'persistent', this is done only for persistent messages. - - - - - sync_ack - - - Boolean - - - A sync command is sent after every acknowledgement to guarantee that it has been received. - - - - - use_legacy_map_msg_format - - - Boolean - - - If you are using JMS Map messages and deploying a new client with any JMS client older than 0.8 release, you must set this to true to ensure the older clients can understand the map message encoding. - - - - - failover - - - {'singlebroker' | 'roundrobin' | 'failover_exchange' | 'nofailover' | '<class>'} - - - - This option controls failover behaviour. The method singlebroker uses only the first broker in the list, - roundrobin will try each broker given in the broker list until a connection is established, - failover_exchange connects to the initial broker given in the broker URL and will receive membership updates - via the failover exchange. nofailover disables all retry and failover logic. Any other value is interpreted as a - classname which must implement the org.apache.qpid.jms.failover.FailoverMethod interface. - - - The broker list options retries and connectdelay (described below) determine the number of times a - connection to a broker will be retried and the the length of time to wait between successive connection attempts before moving on to - the next broker in the list. The failover option cyclecount controls the number of times to loop through the list of - available brokers before finally giving up. - - - Defaults to roundrobin if the brokerlist contains multiple brokers, or singlebroker otherwise. - - - - - -
- - Broker lists are specified using a URL in this format: - - - brokerlist=<transport>://<host>[:<port>](?<param>='<value>')(&<param>='<value>')* - - For instance, this is a typical broker list: - - - brokerlist='tcp://localhost:5672' - - - - A broker list can contain more than one broker address; if so, the connection is made to the first broker in the list that is available. In general, it is better to use the failover exchange when using multiple brokers, since it allows applications to fail over if a broker goes down. - - - - Broker Lists - A broker list can specify properties to be used when connecting to the broker, such as security options. This broker list specifies options for a Kerberos connection using GSSAPI: - - - This broker list specifies SSL options: - - - - - This broker list specifies two brokers using the connectdelay and retries broker options. It also illustrates the failover connection URL - property. - - - - - - The following broker list options are supported. - - - Broker List Options - - - - - Option - - - Type - - - Description - - - - - - - heartbeat - - - integer - - - frequency of heartbeat messages (in seconds) - - - - - sasl_mechs - - - -- - - - For secure applications, we suggest CRAM-MD5, - DIGEST-MD5, or GSSAPI. The ANONYMOUS method is not - secure. The PLAIN method is secure only when used - together with SSL. For Kerberos, sasl_mechs must be - set to GSSAPI, sasl_protocol must be set to the - principal for the qpidd broker, e.g. qpidd/, and - sasl_server must be set to the host for the SASL - server, e.g. sasl.com. SASL External is supported - using SSL certification, e.g. - ssl='true'&sasl_mechs='EXTERNAL' - - - - - sasl_encryption - - - Boolean - - - If sasl_encryption='true', the JMS client attempts to negotiate a security layer with the broker using GSSAPI to encrypt the connection. Note that for this to happen, GSSAPI must be selected as the sasl_mech. - - - - - sasl_protocol - - - -- - - - Used only for - Kerberos. sasl_protocol must be - set to the principal for the qpidd broker, - e.g. qpidd/ - - - - - sasl_server - - - -- - - - For Kerberos, sasl_mechs must be set to GSSAPI, - sasl_server must be set to the host for the SASL - server, e.g. sasl.com. - - - - - trust_store - - - -- - - - path to trust store - - - - - trust_store_password - - - - - Trust store password - - - - - key_store - - - - - path to key store - - - - - key_store_password - - - -- - - - key store password - - - - - ssl - - - Boolean - - - If ssl='true', the JMS client will encrypt the connection using SSL. - - - - - ssl_verify_hostname - - - Boolean - - - When using SSL you can enable hostname verification - by using ssl_verify_hostname='true' in the broker - URL. - - - - - ssl_cert_alias - - - - - - If multiple certificates are present in the keystore, the alias will be used to extract the correct certificate. - - - - - retries - - - integer - - - The number of times to retry connection to each broker in the broker list. Defaults to 1. - - - - - connectdelay - - - integer - - - Length of time (in milliseconds) to wait before attempting to reconnect. Defaults to 0. - - - - - connecttimeout - - - integer - - - Length of time (in milliseconds) to wait for the socket connection to succeed. A value of 0 represents an infinite timeout, i.e. the connection attempt will block until established or an error occurs. Defaults to 30000. - - - - - tcp_nodelay - - - Boolean - - - If tcp_nodelay='true', TCP packet - batching is disabled. Defaults to true since Qpid 0.14. - - - - -
-
-
- -
- Java JMS Message Properties - - The following table shows how Qpid Messaging API message - properties are mapped to AMQP 0-10 message properties and - delivery properties. In this table msg - refers to the Message class defined in the Qpid Messaging API, - mp refers to an AMQP 0-10 - message-properties struct, and - dp refers to an AMQP 0-10 - delivery-properties struct. - - - Java JMS Mapping to AMQP 0-10 Message Properties - - - - Java JMS Message Property - AMQP 0-10 PropertyIn these entries, mp refers to an AMQP message property, and dp refers to an AMQP delivery property. - - - - - - JMSMessageIDmp.message_id - - - qpid.subjectThis is a custom JMS property, set automatically by the Java JMS client implementation.mp.application_headers["qpid.subject"] - - - JMSXUserIDmp.user_id - - - JMSReplyTomp.reply_toThe reply_to is converted from the protocol representation into an address. - - - JMSCorrelationIDmp.correlation_id - - - JMSDeliveryModedp.delivery_mode - - - JMSPrioritydp.priority - - - JMSExpirationdp.ttlJMSExpiration = dp.ttl + currentTime - - - JMSRedelivereddp.redelivered - - - JMS Propertiesmp.application_headers - - - JMSTypemp.content_type - - - -
- -
- -
- JMS MapMessage Types - - Qpid supports the Java JMS MapMessage interface, which provides support for maps in messages. The following code shows how to send a MapMessage in Java JMS. - - - Sending a Java JMS MapMessage - colors = new ArrayList(); - colors.add("red"); - colors.add("green"); - colors.add("white"); - m.setObject("colours", colors); - - Map dimensions = new HashMap(); - dimensions.put("length",10.2); - dimensions.put("width",5.1); - dimensions.put("depth",2.0); - m.setObject("dimensions",dimensions); - - List> parts = new ArrayList>(); - parts.add(Arrays.asList(new Integer[] {1,2,5})); - parts.add(Arrays.asList(new Integer[] {8,2,5})); - m.setObject("parts", parts); - - Map specs = new HashMap(); - specs.put("colours", colors); - specs.put("dimensions", dimensions); - specs.put("parts", parts); - m.setObject("specs",specs); - - producer.send(m); - ]]> - - - The following table shows the datatypes that can be sent in a MapMessage, and the corresponding datatypes that will be received by clients in Python or C++. - - - Java Datatypes in Maps - - - - Java Datatype - → Python - → C++ - - - - booleanboolbool - shortint | longint16 - intint | longint32 - longint | longint64 - floatfloatfloat - doublefloatdouble - java.lang.Stringunicodestd::string - java.util.UUIDuuidqpid::types::Uuid - java.util.MapIn Qpid, maps can nest. This goes beyond the functionality required by the JMS specification.dictVariant::Map - java.util.ListlistVariant::List - - -
- -
- -
- JMS Client Logging - The JMS Client logging is handled using the Simple Logging Facade for Java (SLF4J). As the name implies, slf4j is a facade that delegates to other logging systems like log4j or JDK 1.4 logging. For more information on how to configure slf4j for specific logging systems, please consult the slf4j documentation. - - When using the log4j binding, please set the log level for org.apache.qpid explicitly. Otherwise log4j will default to DEBUG which will degrade performance considerably due to excessive logging. The recommended logging level for production is WARN. - - The following example shows the logging properties used to configure client logging for slf4j using the log4j binding. These properties can be placed in a log4j.properties file and placed in the CLASSPATH, or they can be set explicitly using the -Dlog4j.configuration property. - - - log4j Logging Properties - - - - -
- -
- Configuring the JMS Client - - The Qpid JMS Client allows several configuration options to customize it's behaviour at different levels of granualarity. - - - - - JVM level using JVM arguments : Configuration that affects all connections, sessions, consumers and producers created within that JVM. - - Ex. -Dmax_prefetch=1000 property specifies the message credits to use. - - - - - Connection level using Connection/Broker properties : Affects the respective connection and sessions, consumers and produces created by that connection. - - Ex. amqp://guest:guest@test/test?max_prefetch='1000' - &brokerlist='tcp://localhost:5672' - property specifies the message credits to use. This overrides any value specified via the JVM argument max_prefetch. - Please refer to the section for a complete list of all properties and how to use them. - - - - - Destination level using Addressing options : Affects the producer(s) and consumer(s) created using the respective destination. - - Ex. my-queue; {create: always, link:{capacity: 10}}, where capacity option specifies the message credits to use. This overrides any connection level configuration. - Please refer to the section for a complete understanding of addressing and it's various options. - - - - Some of these config options are available at all three levels (Ex. max_prefetch), while others are available only at JVM or connection level. - -
- Qpid JVM Arguments - - - Config Options For Connection Behaviour - - - - Property Name - Type - Default Value - Description - - - - - qpid.amqp.version - string - 0-10 - Sets the AMQP version to be used - currently supports one of {0-8,0-9,0-91,0-10}.The client will begin negotiation at the specified version and only negotiate downwards if the Broker does not support the specified version. - - - qpid.heartbeat - int - 120 (secs) - The heartbeat interval in seconds. Two consective misssed heartbeats will result in the connection timing out.This can also be set per connection using the Connection URL options. - - - - ignore_setclientID - boolean - false - If a client ID is specified in the connection URL it's used or else an ID is generated. If an ID is specified after it's been set Qpid will throw an exception. Setting this property to 'true' will disable that check and allow you to set a client ID of your choice later on. - - - -
- - - - Config Options For Session Behaviour - - - - Property Name - Type - Default Value - Description - - - - - qpid.session.command_limit - int - 65536 - Limits the # of unacked commands - - - - qpid.session.byte_limit - int - 1048576 - Limits the # of unacked commands in terms of bytes - - - - qpid.use_legacy_map_message - boolean - false - If set will use the old map message encoding. By default the Map messages are encoded using the 0-10 map encoding.This can also be set per connection using the Connection URL options. - - - - qpid.jms.daemon.dispatcher - boolean - false - Controls whether the Session dispatcher thread is a daemon thread or not. If this system property is set to true then the Session dispatcher threads will be created as daemon threads. This setting is introduced in version 0.16. - - - -
- - - Config Options For Consumer Behaviour - - - - Property Name - Type - Default Value - Description - - - - - max_prefetch - int - 500 - Maximum number of pre-fetched messages per consumer. This can also be defaulted for consumers created on a particular connection using the Connection URL options, or per destination (see the capacity option under link properties in addressing) - - - - qpid.session.max_ack_delay - long - 1000 (ms) - Timer interval to flush message acks in buffer when using AUTO_ACK and DUPS_OK. When using the above ack modes, message acks are batched and sent if one of the following conditions are met (which ever happens first). - - When the ack timer fires. - if un_acked_msg_count > max_prefetch/2. - - - The ack timer can be disabled by setting it to 0. - - - - - sync_ack - boolean - false - If set, each message will be acknowledged synchronously. When using AUTO_ACK mode, you need to set this to "true", in order to get the correct behaviour as described by the JMS spec.This is set to false by default for performance reasons, therefore by default AUTO_ACK behaves similar to DUPS_OK.This can also be set per connection using the Connection URL options. - - - -
- - - Config Options For Producer Behaviour - - - - Property Name - Type - Default Value - Description - - - - - sync_publish - string - "" (disabled) - If one of {persistent|all} is set then persistent messages or all messages will be sent synchronously.This can also be set per connection using the Connection URL options. - - - -
- - - Config Options For Threading - - - - Property Name - Type - Default Value - Description - - - - - qpid.thread_factory - string - org.apache.qpid.thread.DefaultThreadFactory - Specifies the thread factory to use.If using a real time JVM, you need to set the above property to org.apache.qpid.thread.RealtimeThreadFactory. - - - - qpid.rt_thread_priority - int - 20 - Specifies the priority (1-99) for Real time threads created by the real time thread factory. - - - -
- - - Config Options For I/O - - - - Property Name - Type - Default Value - Description - - - - - qpid.transport - string - org.apache.qpid.transport.network.io.IoNetworkTransport - The transport implementation to be used.A user could specify an alternative transport mechanism that implements the interface org.apache.qpid.transport.network.OutgoingNetworkTransport. - - - qpid.sync_op_timeout - long - 60000 - The length of time (in milliseconds) to wait for a synchronous operation to complete.For compatibility with older clients, the synonym amqj.default_syncwrite_timeout is supported. - - - qpid.tcp_nodelay - boolean - true - - Sets the TCP_NODELAY property of the underlying socket. The default was changed to true as of Qpid 0.14. - This can also be set per connection using the Connection URL options. - For compatibility with older clients, the synonym amqj.tcp_nodelay is supported. - - - - qpid.send_buffer_size - integer - 65535 - - Sets the SO_SNDBUF property of the underlying socket. Added in Qpid 0.16. - For compatibility with older clients, the synonym amqj.sendBufferSize is supported. - - - - qpid.receive_buffer_size - integer - 65535 - - Sets the SO_RCVBUF property of the underlying socket. Added in Qpid 0.16. - For compatibility with older clients, the synonym amqj.receiveBufferSize is supported. - - - - qpid.failover_method_timeout - long - 60000 - - During failover, this is the timeout for each attempt to try to re-establish the connection. - If a reconnection attempt exceeds the timeout, the entire failover process is aborted. - It is only applicable for AMQP 0-8/0-9/0-9-1 clients. - - - - -
- - - Config Options For Security - - - - Property Name - Type - Default Value - Description - - - - - qpid.sasl_mechs - string - PLAIN - The SASL mechanism to be used. More than one could be specified as a comma separated list.We currently support the following mechanisms {PLAIN | GSSAPI | EXTERNAL}.This can also be set per connection using the Connection URL options. - - - - qpid.sasl_protocol - string - AMQP - When using GSSAPI as the SASL mechanism, sasl_protocol must be set to the principal for the qpidd broker, e.g. qpidd.This can also be set per connection using the Connection URL options. - - - - qpid.sasl_server_name - string - localhost - When using GSSAPI as the SASL mechanism, sasl_server must be set to the host for the SASL server, e.g. example.com.This can also be set per connection using the Connection URL options. - - - -
- - - Config Options For Security - Standard JVM properties needed when using GSSAPI as the SASL mechanism.<footnote><para>Please refer to the Java security documentation for a complete understanding of the above properties.</para></footnote> - - - - Property Name - Type - Default Value - Description - - - - - javax.security.auth.useSubjectCredsOnly - boolean - true - If set to 'false', forces the SASL GASSPI client to obtain the kerberos credentials explicitly instead of obtaining from the "subject" that owns the current thread. - - - - java.security.auth.login.config - string - - Specifies the jass configuration file.Ex-Djava.security.auth.login.config=myjas.conf - Here is the sample myjas.conf JASS configuration file: - - - -
- - - Config Options For Security - Using SSL for securing connections or using EXTERNAL as the SASL mechanism. - - - - Property Name - Type - Default Value - Description - - - - - qpid.ssl_timeout - long - 60000 - Timeout value used by the Java SSL engine when waiting on operations. - - - - qpid.ssl.KeyManagerFactory.algorithm - string - - - - The key manager factory algorithm name. If not set, defaults to the value returned from the Java runtime call KeyManagerFactory.getDefaultAlgorithm() - For compatibility with older clients, the synonym qpid.ssl.keyStoreCertType is supported. - - - - - qpid.ssl.TrustManagerFactory.algorithm - string - - - - The trust manager factory algorithm name. If not set, defaults to the value returned from the Java runtime call TrustManagerFactory.getDefaultAlgorithm() - For compatibility with older clients, the synonym qpid.ssl.trustStoreCertType is supported. - - - - -
- - - Config Options For Security - Standard JVM properties needed when Using SSL for securing connections or using EXTERNAL as the SASL mechanism.<footnote><para>Qpid allows you to have per connection key and trust stores if required. If specified per connection, the JVM arguments are ignored.</para></footnote> - - - - Property Name - Type - Default Value - Description - - - - - javax.net.ssl.keyStore - string - jvm default - Specifies the key store path.This can also be set per connection using the Connection URL options. - - - - javax.net.ssl.keyStorePassword - string - jvm default - Specifies the key store password.This can also be set per connection using the Connection URL options. - - - - javax.net.ssl.trustStore - string - jvm default - Specifies the trust store path.This can also be set per connection using the Connection URL options. - - - - javax.net.ssl.trustStorePassword - string - jvm default - Specifies the trust store password.This can also be set per connection using the Connection URL options. - - - -
-
-
- - - - - Using the Qpid WCF client -
- XML and Binary Bindings - - The Qpid WCF client provides two bindings, each with support for - Windows .NET transactions. - - The AmqpBinding is suitable for communication between two WCF - applications. By default it uses the WCF binary .NET XML encoder - (BinaryMessageEncodingBindingElement) for efficient message - transmission, but it can also use the text and Message Transmission - Optimization Mechanism (MTOM) encoders. Here is a traditional service - model sample program using the AmqpBinding. It assumes that the queue - "hello_service_node" has been created and configured on the AMQP - broker. - - - Traditional service model "Hello world!" example - - - channelFactory = - new ChannelFactory(amqpBinding, clientEndpoint); - IHelloService clientProxy = channelFactory.CreateChannel(); - - clientProxy.SayHello("Greetings from WCF client"); - - // wait for service to process the greeting - while (HelloService.GreetingCount == 0) - { - Thread.Sleep(100); - } - channelFactory.Close(); - serviceHost.Close(); - } - catch (Exception e) - { - Console.WriteLine("Exception: {0}", e); - } - } - } - } - ]]> - - - The second binding, AmqpBinaryBinding, is suitable for WCF - applications that need to inter-operate with non-WCF clients or that - wish to have direct access to the raw wire representation of the - message body. It relies on a custom encoder to read and write raw - (binary) content which operates similarly to the ByteStream encoder - (introduced in .NET 4.0). The encoder presents an abstract XML - infoset view of the raw message content on input. On output, the - encoder does the reverse and peels away the XML infoset layer exposing - the raw content to the wire representation of the message body. The - application must do the inverse of what the encoder does to allow the - XML infoset wrapper to cancel properly. This is demonstrated in the - following sample code (using the channel programming model) which - directly manipulates or provides callbacks to the WCF message readers - and writers when the content is consumed. In contrast to the - AmqpBinding sample where the simple greeting is encapsulated in a - compressed SOAP envelope, the wire representation of the message - contains the raw content and is identical and fully interoperable with - the Qpid C++ "Hello world!" example. - - - Binary "Hello world!" example using the channel model - 0) - { - broker = args[0]; - } - - if (args.Length > 1) - { - port = int.Parse(args[1]); - } - - if (args.Length > 2) - { - target = args[2]; - } - - if (args.Length > 3) - { - source = args[3]; - } - - AmqpBinaryBinding binding = new AmqpBinaryBinding(); - binding.BrokerHost = broker; - binding.BrokerPort = port; - - IChannelFactory receiverFactory = binding.BuildChannelFactory(); - receiverFactory.Open(); - IInputChannel receiver = receiverFactory.CreateChannel(new EndpointAddress("amqp:" + source)); - receiver.Open(); - - IChannelFactory senderFactory = binding.BuildChannelFactory(); - senderFactory.Open(); - IOutputChannel sender = senderFactory.CreateChannel(new EndpointAddress("amqp:" + target)); - sender.Open(); - - sender.Send(Message.CreateMessage(MessageVersion.None, "", new HelloWorldBinaryBodyWriter())); - - Message message = receiver.Receive(); - XmlDictionaryReader reader = message.GetReaderAtBodyContents(); - while (!reader.HasValue) - { - reader.Read(); - } - - byte[] binaryContent = reader.ReadContentAsBase64(); - string text = Encoding.UTF8.GetString(binaryContent); - - Console.WriteLine(text); - - senderFactory.Close(); - receiverFactory.Close(); - } - } - - public class HelloWorldBinaryBodyWriter : BodyWriter - { - public HelloWorldBinaryBodyWriter() : base (true) {} - - protected override void OnWriteBodyContents(XmlDictionaryWriter writer) - { - byte[] binaryContent = Encoding.UTF8.GetBytes("Hello world!"); - - // wrap the content: - writer.WriteStartElement("Binary"); - writer.WriteBase64(binaryContent, 0, binaryContent.Length); - } - } - } - ]]> - - - Bindings define ChannelFactories and ChannelListeners associated with - an AMQP Broker. WCF will frequently automatically create and manage - the life cycle of a these and the resulting IChannel objects used in - message transfer. The binding parameters that can be set are: - - - WCF Binding Parameters - - - - - - - Parameter - Default - Description - - - - - - BrokerHost - - - localhost - - - The broker's server name. Currently the WCF channel - only supports connections with a single broker. - Failover to multiple brokers will be provided in the - future. - - - - - - BrokerPort - - - 5672 - - - The port the broker is listening on. - - - - - - PrefetchLimit - - - 0 - - - The number of messages to prefetch from the amqp - broker before the application actually consumes them. - Increasing this number can dramatically increase the - read performance in some circumstances. - - - - - - Shared - - - false - - - Indicates if separate channels to the same broker can - share an underlying AMQP tcp connection (provided they - also share the same authentication credentials). - - - - - - TransferMode - - - buffered - - - Indicates whether the channel's encoder uses the WCF - BufferManager cache to temporarily store message - content during the encoding/decoding phase. For small - to medium sized SOAP based messages, buffered is - usually the preferred choice. For binary messages, - streamed TransferMode is the more efficient mode. - - - - -
-
- -
- Endpoints - - In Qpid 0.6 the WCF Endpoints map to simple AMQP 0-10 - exchanges (IOutputChannel) or AMQP 0-10 queues (IInputChannel). - The format for an IOutputChannel is - - - - and for an IInputChannel is - - - - The routing key is in fact a default value associated with - the particular channel. Outgoing messages can always have their - routing key uniquely set. - - If the respective queue or exchange doesn't exist, an exception - is thrown when opening the channel. Queues and exchanges can be - created and configured using qpid-config. - -
- -
- Message Headers - - AMQP specific message headers can be set on or retrieved - from the ServiceModel.Channels.Message using the AmqpProperties - type. - - For example, on output: - - - - On input the headers can be accessed from the Message or extracted - from the operation context - - - -
- -
- Security - - To engage TLS/SSL: - - - - Currently the WCF client only provides SASL PLAIN (i.e. username and - password) authentication. To provide a username and password, you can - set the DefaultAmqpCredential value in the binding. This value can be - overridden or set for a binding's channel factories and listeners, - either by setting the ClientCredentials as a binding parameter, or by - using an AmqpCredential as a binding parameter. The search order for - credentials is the AmqpCredential binding parameter, followed by the - ClientCredentials (unless IgnoreEndpointClientCredentials has been - set), and finally defaulting to the DefaultAmqpCredential of the - binding itself. Here is a sample using ClientCredentials: - - (bindingParameters); -]]> - -
- -
- Transactions - - The WCF channel provides a transaction resource manager - module and a recovery module that together provide distributed - transaction support with one-phase optimization. Some - configuration is required on Windows machines to enable - transaction support (see your installation notes or top level - ReadMe.txt file for instructions). Once properly configured, - the Qpid WCF channel acts as any other System.Transactions aware - resource, capable of participating in explicit or implicit - transactions. - - Server code: - - - - Because this operation involves two transaction resources, the - database and the AMQP message broker, this operates as a full two - phase commit transaction managed by the Distributed Transaction - Coordinator service. If the transaction proceeds without error, - both ExactlyOnceReceived is incremented in the database and the AMQP - message is consumed from the broker. Otherwise, ExactlyOnceReceived is - unchanged and AMQP message is returned to its queue on the broker. - - For the client code a few changes are made to the non-transacted - example. For "exactly once" semantics, we set the AMQP "Durable" - message property and enclose the transacted activities in a - TransactionScope: - - channelFactory = -new ChannelFactory(amqpBinding, clientEndpoint); -IHelloService clientProxy = channelFactory.CreateChannel(); - -using (TransactionScope ts = new TransactionScope()) -{ - AmqpProperties amqpProperties = new AmqpProperties(); - clientProxy.SayHello("Greetings from WCF client"); - // increment ExactlyOnceSent counter on DB - ts.Complete(); -} -]]> - -
- - - - The .NET Binding for the C++ Messaging Client - - The .NET Binding for the C++ Qpid Messaging Client is a library that gives - any .NET program access to Qpid C++ Messaging objects and methods. - -
- .NET Binding for the C++ Messaging Client Component Architecture - - - - -This diagram illustrates the code and library components of the binding -and the hierarchical relationships between them. - - - .NET Binding for the C++ Messaging Client Component Architecture - - - - Component Name - Component Function - - - - - QPID Messaging C++ Libraries - The QPID Messaging C++ core run time system - - - Unmanaged C++ Example Source Programs - Ordinary C++ programs that illustrate using qpid/cpp Messaging directly - in a native Windows environment. - - - .NET Messaging Binding Library - The .NET Messaging Binding library provides interoprability between - managed .NET programs and the unmanaged, native Qpid Messaging C++ core - run time system. .NET programs create a Reference to this library thereby - exposing all of the native C++ Messaging functionality to programs - written in any .NET language. - - - .NET Messaging Managed Callback Library - An extension of the .NET Messaging Binding Library that provides message - callbacks in a managed .NET environment. - - - Managed C# .NET Example Source Programs - Various C# example programs that illustrate using .NET Binding for C++ Messaging in the .NET environment. - - - -
-
- -
- .NET Binding for the C++ Messaging Client Examples - - This chapter describes the various sample programs that - are available to illustrate common Qpid Messaging usage. - - - Example : Client - Server - - - - - - Example Name - Example Description - - - - - csharp.example.server - Creates a Receiver and listens for messages. - Upon message reception the message content is converted to upper case - and forwarded to the received message's ReplyTo address. - - - csharp.example.client - Sends a series of messages to the Server and prints the original message - content and the received message content. - - - -
- - - Example : Map Sender – Map Receiver - - - - - - Example Name - Example Description - - - - - csharp.map.receiver - Creates a Receiver and listens for a map message. - Upon message reception the message is decoded and displayed on the console. - - - csharp.map.sender - Creates a map message and sends it to map.receiver. - The map message contains values for every supported .NET Messaging - Binding data type. - - - -
- - - Example : Spout - Drain - - - - - - Example Name - Example Description - - - - - csharp.example.spout - Spout is a more complex example of code that generates a series of messages - and sends them to peer program Drain. Flexible command line arguments allow - the user to specify a variety of message and program options. - - - csharp.example.drain - Drain is a more complex example of code that receives a series of messages - and displays their contents on the console. - - - -
- - - Example : Map Callback Sender – Map Callback Receiver - - - - - - Example Name - Example Description - - - - - csharp.map.callback.receiver - Creates a Receiver and listens for a map message. - Upon message reception the message is decoded and displayed on the console. - This example illustrates the use of the C# managed code callback mechanism - provided by .NET Messaging Binding Managed Callback Library. - - - csharp.map.callback.sender - Creates a map message and sends it to map_receiver. - The map message contains values for every supported .NET Messaging - Binding data type. - - - -
- - - Example - Declare Queues - - - - - - Example Name - Example Description - - - - - csharp.example.declare_queues - A program to illustrate creating objects on a broker. - This program creates a queue used by spout and drain. - - - -
- - - Example: Direct Sender - Direct Receiver - - - - - - Example Name - Example Description - - - - - csharp.direct.receiver - Creates a Receiver and listens for a messages. - Upon message reception the message is decoded and displayed on the console. - - - csharp.direct.sender - Creates a series of messages and sends them to csharp.direct.receiver. - - - -
- - - Example: Hello World - - - - - - Example Name - Example Description - - - - - csharp.example.helloworld - A program to send a message and to receive the same message. - - - -
- -
- -
- .NET Binding Class Mapping to Underlying C++ Messaging API - - This chapter describes the specific mappings between - classes in the .NET Binding and the underlying C++ Messaging - API. - -
- .NET Binding for the C++ Messaging API Class: Address - - .NET Binding for the C++ Messaging API Class: Address - - - - - - .NET Binding Class: Address - - - Language - Syntax - - - - - C++ - class Address - - - .NET - public ref class Address - - - Constructor - - - C++ - Address(); - - - .NET - public Address(); - - - Constructor - - - C++ - Address(const std::string& address); - - - .NET - public Address(string address); - - - Constructor - - - C++ - Address(const std::string& name, const std::string& subject, const qpid::types::Variant::Map& options, const std::string& type = ""); - - - .NET - public Address(string name, string subject, Dictionary<string, object> options); - - - .NET - public Address(string name, string subject, Dictionary<string, object> options, string type); - - - Copy constructor - - - C++ - Address(const Address& address); - - - .NET - public Address(Address address); - - - Destructor - - - C++ - ~Address(); - - - .NET - ~Address(); - - - Finalizer - - - C++ - n/a - - - .NET - !Address(); - - - Copy assignment operator - - - C++ - Address& operator=(const Address&); - - - .NET - public Address op_Assign(Address rhs); - - - Property: Name - - - C++ - const std::string& getName() const; - - - C++ - void setName(const std::string&); - - - .NET - public string Name { get; set; } - - - Property: Subject - - - C++ - const std::string& getSubject() const; - - - C++ - void setSubject(const std::string&); - - - .NET - public string Subject { get; set; } - - - Property: Options - - - C++ - const qpid::types::Variant::Map& getOptions() const; - - - C++ - qpid::types::Variant::Map& getOptions(); - - - C++ - void setOptions(const qpid::types::Variant::Map&); - - - .NET - public Dictionary<string, object> Options { get; set; } - - - Property: Type - - - C++ - std::string getType() const; - - - C++ - void setType(const std::string&); - - - .NET - public string Type { get; set; } - - - Miscellaneous - - - C++ - std::string str() const; - - - .NET - public string ToStr(); - - - Miscellaneous - - - C++ - operator bool() const; - - - .NET - n/a - - - Miscellaneous - - - C++ - bool operator !() const; - - - .NET - n/a - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Connection - - .NET Binding for the C++ Messaging API Class: Connection - - - - - - .NET Binding Class: Connection - - - Language - Syntax - - - - - C++ - class Connection : public qpid::messaging::Handle<ConnectionImpl> - - - .NET - public ref class Connection - - - Constructor - - - C++ - Connection(ConnectionImpl* impl); - - - .NET - n/a - - - Constructor - - - C++ - Connection(); - - - .NET - n/a - - - Constructor - - - C++ - Connection(const std::string& url, const qpid::types::Variant::Map& options = qpid::types::Variant::Map()); - - - .NET - public Connection(string url); - - - .NET - public Connection(string url, Dictionary<string, object> options); - - - Constructor - - - C++ - Connection(const std::string& url, const std::string& options); - - - .NET - public Connection(string url, string options); - - - Copy Constructor - - - C++ - Connection(const Connection&); - - - .NET - public Connection(Connection connection); - - - Destructor - - - C++ - ~Connection(); - - - .NET - ~Connection(); - - - Finalizer - - - C++ - n/a - - - .NET - !Connection(); - - - Copy assignment operator - - - C++ - Connection& operator=(const Connection&); - - - .NET - public Connection op_Assign(Connection rhs); - - - Method: SetOption - - - C++ - void setOption(const std::string& name, const qpid::types::Variant& value); - - - .NET - public void SetOption(string name, object value); - - - Method: open - - - C++ - void open(); - - - .NET - public void Open(); - - - Property: isOpen - - - C++ - bool isOpen(); - - - .NET - public bool IsOpen { get; } - - - Method: close - - - C++ - void close(); - - - .NET - public void Close(); - - - Method: createTransactionalSession - - - C++ - Session createTransactionalSession(const std::string& name = std::string()); - - - .NET - public Session CreateTransactionalSession(); - - - .NET - public Session CreateTransactionalSession(string name); - - - Method: createSession - - - C++ - Session createSession(const std::string& name = std::string()); - - - .NET - public Session CreateSession(); - - - .NET - public Session CreateSession(string name); - - - Method: getSession - - - C++ - Session getSession(const std::string& name) const; - - - .NET - public Session GetSession(string name); - - - Property: AuthenticatedUsername - - - C++ - std::string getAuthenticatedUsername(); - - - .NET - public string GetAuthenticatedUsername(); - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Duration - - .NET Binding for the C++ Messaging API Class: Duration - - - - - - .NET Binding Class: Duration - - - Language - Syntax - - - - - C++ - class Duration - - - .NET - public ref class Duration - - - Constructor - - - C++ - explicit Duration(uint64_t milliseconds); - - - .NET - public Duration(ulong mS); - - - Copy constructor - - - C++ - n/a - - - .NET - public Duration(Duration rhs); - - - Destructor - - - C++ - default - - - .NET - default - - - Finalizer - - - C++ - n/a - - - .NET - default - - - Property: Milliseconds - - - C++ - uint64_t getMilliseconds() const; - - - .NET - public ulong Milliseconds { get; } - - - Operator: * - - - C++ - Duration operator*(const Duration& duration, uint64_t multiplier); - - - .NET - public static Duration operator *(Duration dur, ulong multiplier); - - - .NET - public static Duration Multiply(Duration dur, ulong multiplier); - - - C++ - Duration operator*(uint64_t multiplier, const Duration& duration); - - - .NET - public static Duration operator *(ulong multiplier, Duration dur); - - - .NET - public static Duration Multiply(ulong multiplier, Duration dur); - - - Constants - - - C++ - static const Duration FOREVER; - - - C++ - static const Duration IMMEDIATE; - - - C++ - static const Duration SECOND; - - - C++ - static const Duration MINUTE; - - - .NET - public sealed class DurationConstants - - - .NET - public static Duration FORVER; - - - .NET - public static Duration IMMEDIATE; - - - .NET - public static Duration MINUTE; - - - .NET - public static Duration SECOND; - - - -
-
-
- .NET Binding for the C++ Messaging API Class: FailoverUpdates - - .NET Binding for the C++ Messaging API Class: FailoverUpdates - - - - - - .NET Binding Class: FailoverUpdates - - - Language - Syntax - - - - - C++ - class FailoverUpdates - - - .NET - public ref class FailoverUpdates - - - Constructor - - - C++ - FailoverUpdates(Connection& connection); - - - .NET - public FailoverUpdates(Connection connection); - - - Destructor - - - C++ - ~FailoverUpdates(); - - - .NET - ~FailoverUpdates(); - - - Finalizer - - - C++ - n/a - - - .NET - !FailoverUpdates(); - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Message - - .NET Binding for the C++ Messaging API Class: Message - - - - - - .NET Binding Class: Message - - - Language - Syntax - - - - - C++ - class Message - - - .NET - public ref class Message - - - Constructor - - - C++ - Message(const std::string& bytes = std::string()); - - - .NET - Message(); - - - .NET - Message(System::String ^ theStr); - - - .NET - Message(System::Object ^ theValue); - - - .NET - Message(array<System::Byte> ^ bytes); - - - Constructor - - - C++ - Message(const char*, size_t); - - - .NET - public Message(byte[] bytes, int offset, int size); - - - - Copy constructor - - - C++ - Message(const Message&); - - - .NET - public Message(Message message); - - - - Copy assignment operator - - - C++ - Message& operator=(const Message&); - - - .NET - public Message op_Assign(Message rhs); - - - Destructor - - - C++ - ~Message(); - - - .NET - ~Message(); - - - Finalizer - - - C++ - n/a - - - .NET - !Message() - - - Property: ReplyTo - - - C++ - void setReplyTo(const Address&); - - - C++ - const Address& getReplyTo() const; - - - .NET - public Address ReplyTo { get; set; } - - - Property: Subject - - - C++ - void setSubject(const std::string&); - - - C++ - const std::string& getSubject() const; - - - .NET - public string Subject { get; set; } - - - Property: ContentType - - - C++ - void setContentType(const std::string&); - - - C++ - const std::string& getContentType() const; - - - .NET - public string ContentType { get; set; } - - - Property: MessageId - - - C++ - void setMessageId(const std::string&); - - - C++ - const std::string& getMessageId() const; - - - .NET - public string MessageId { get; set; } - - - Property: UserId - - - C++ - void setUserId(const std::string&); - - - C++ - const std::string& getUserId() const; - - - .NET - public string UserId { get; set; } - - - Property: CorrelationId - - - C++ - void setCorrelationId(const std::string&); - - - C++ - const std::string& getCorrelationId() const; - - - .NET - public string CorrelationId { get; set; } - - - Property: Priority - - - C++ - void setPriority(uint8_t); - - - C++ - uint8_t getPriority() const; - - - .NET - public byte Priority { get; set; } - - - Property: Ttl - - - C++ - void setTtl(Duration ttl); - - - C++ - Duration getTtl() const; - - - .NET - public Duration Ttl { get; set; } - - - Property: Durable - - - C++ - void setDurable(bool durable); - - - C++ - bool getDurable() const; - - - .NET - public bool Durable { get; set; } - - - Property: Redelivered - - - C++ - bool getRedelivered() const; - - - C++ - void setRedelivered(bool); - - - .NET - public bool Redelivered { get; set; } - - - Method: SetProperty - - - C++ - void setProperty(const std::string&, const qpid::types::Variant&); - - - .NET - public void SetProperty(string name, object value); - - - Property: Properties - - - C++ - const qpid::types::Variant::Map& getProperties() const; - - - C++ - qpid::types::Variant::Map& getProperties(); - - - .NET - public Dictionary<string, object> Properties { get; set; } - - - Method: SetContent - - - C++ - void setContent(const std::string&); - - - C++ - void setContent(const char* chars, size_t count); - - - .NET - public void SetContent(byte[] bytes); - - - .NET - public void SetContent(string content); - - - .NET - public void SetContent(byte[] bytes, int offset, int size); - - - Method: GetContent - - - C++ - std::string getContent() const; - - - .NET - public string GetContent(); - - - .NET - public void GetContent(byte[] arr); - - - .NET - public void GetContent(Collection<object> __p1); - - - .NET - public void GetContent(Dictionary<string, object> dict); - - - Method: GetContentPtr - - - C++ - const char* getContentPtr() const; - - - .NET - n/a - - - Property: ContentSize - - - C++ - size_t getContentSize() const; - - - .NET - public ulong ContentSize { get; } - - - Struct: EncodingException - - - C++ - struct EncodingException : qpid::types::Exception - - - .NET - n/a - - - Method: decode - - - C++ - void decode(const Message& message, qpid::types::Variant::Map& map, const std::string& encoding = std::string()); - - - C++ - void decode(const Message& message, qpid::types::Variant::List& list, const std::string& encoding = std::string()); - - - .NET - n/a - - - Method: encode - - - C++ - void encode(const qpid::types::Variant::Map& map, Message& message, const std::string& encoding = std::string()); - - - C++ - void encode(const qpid::types::Variant::List& list, Message& message, const std::string& encoding = std::string()); - - - .NET - n/a - - - Method: AsString - - - C++ - n/a - - - .NET - public string AsString(object obj); - - - .NET - public string ListAsString(Collection<object> list); - - - .NET - public string MapAsString(Dictionary<string, object> dict); - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Receiver - - .NET Binding for the C++ Messaging API Class: Receiver - - - - - - .NET Binding Class: Receiver - - - Language - Syntax - - - - - C++ - class Receiver - - - .NET - public ref class Receiver - - - Constructor - - - .NET - Constructed object is returned by Session.CreateReceiver - - - Copy constructor - - - C++ - Receiver(const Receiver&); - - - .NET - public Receiver(Receiver receiver); - - - Destructor - - - C++ - ~Receiver(); - - - .NET - ~Receiver(); - - - Finalizer - - - C++ - n/a - - - .NET - !Receiver() - - - Copy assignment operator - - - C++ - Receiver& operator=(const Receiver&); - - - .NET - public Receiver op_Assign(Receiver rhs); - - - Method: Get - - - C++ - bool get(Message& message, Duration timeout=Duration::FOREVER); - - - .NET - public bool Get(Message mmsgp); - - - .NET - public bool Get(Message mmsgp, Duration durationp); - - - Method: Get - - - C++ - Message get(Duration timeout=Duration::FOREVER); - - - .NET - public Message Get(); - - - .NET - public Message Get(Duration durationp); - - - Method: Fetch - - - C++ - bool fetch(Message& message, Duration timeout=Duration::FOREVER); - - - .NET - public bool Fetch(Message mmsgp); - - - .NET - public bool Fetch(Message mmsgp, Duration duration); - - - Method: Fetch - - - C++ - Message fetch(Duration timeout=Duration::FOREVER); - - - .NET - public Message Fetch(); - - - .NET - public Message Fetch(Duration durationp); - - - Property: Capacity - - - C++ - void setCapacity(uint32_t); - - - C++ - uint32_t getCapacity(); - - - .NET - public uint Capacity { get; set; } - - - Property: Available - - - C++ - uint32_t getAvailable(); - - - .NET - public uint Available { get; } - - - Property: Unsettled - - - C++ - uint32_t getUnsettled(); - - - .NET - public uint Unsettled { get; } - - - Method: Close - - - C++ - void close(); - - - .NET - public void Close(); - - - Property: IsClosed - - - C++ - bool isClosed() const; - - - .NET - public bool IsClosed { get; } - - - Property: Name - - - C++ - const std::string& getName() const; - - - .NET - public string Name { get; } - - - Property: Session - - - C++ - Session getSession() const; - - - .NET - public Session Session { get; } - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Sender - - .NET Binding for the C++ Messaging API Class: Sender - - - - - - .NET Binding Class: Sender - - - Language - Syntax - - - - - C++ - class Sender - - - .NET - public ref class Sender - - - Constructor - - - .NET - Constructed object is returned by Session.CreateSender - - - Copy constructor - - - C++ - Sender(const Sender&); - - - .NET - public Sender(Sender sender); - - - Destructor - - - C++ - ~Sender(); - - - .NET - ~Sender(); - - - Finalizer - - - C++ - n/a - - - .NET - !Sender() - - - Copy assignment operator - - - C++ - Sender& operator=(const Sender&); - - - .NET - public Sender op_Assign(Sender rhs); - - - Method: Send - - - C++ - void send(const Message& message, bool sync=false); - - - .NET - public void Send(Message mmsgp); - - - .NET - public void Send(Message mmsgp, bool sync); - - - Method: Close - - - C++ - void close(); - - - .NET - public void Close(); - - - Property: Capacity - - - C++ - void setCapacity(uint32_t); - - - C++ - uint32_t getCapacity(); - - - .NET - public uint Capacity { get; set; } - - - Property: Available - - - C++ - uint32_t getAvailable(); - - - .NET - public uint Available { get; } - - - Property: Unsettled - - - C++ - uint32_t getUnsettled(); - - - .NET - public uint Unsettled { get; } - - - Property: Name - - - C++ - const std::string& getName() const; - - - .NET - public string Name { get; } - - - Property: Session - - - C++ - Session getSession() const; - - - .NET - public Session Session { get; } - - - -
-
-
- .NET Binding for the C++ Messaging API Class: Session - - .NET Binding for the C++ Messaging API Class: Session - - - - - - .NET Binding Class: Session - - - Language - Syntax - - - - - C++ - class Session - - - .NET - public ref class Session - - - Constructor - - - .NET - Constructed object is returned by Connection.CreateSession - - - Copy constructor - - - C++ - Session(const Session&); - - - .NET - public Session(Session session); - - - Destructor - - - C++ - ~Session(); - - - .NET - ~Session(); - - - Finalizer - - - C++ - n/a - - - .NET - !Session() - - - Copy assignment operator - - - C++ - Session& operator=(const Session&); - - - .NET - public Session op_Assign(Session rhs); - - - Method: Close - - - C++ - void close(); - - - .NET - public void Close(); - - - Method: Commit - - - C++ - void commit(); - - - .NET - public void Commit(); - - - Method: Rollback - - - C++ - void rollback(); - - - .NET - public void Rollback(); - - - Method: Acknowledge - - - C++ - void acknowledge(bool sync=false); - - - C++ - void acknowledge(Message&, bool sync=false); - - - .NET - public void Acknowledge(); - - - .NET - public void Acknowledge(bool sync); - - - .NET - public void Acknowledge(Message __p1); - - - .NET - public void Acknowledge(Message __p1, bool __p2); - - - Method: Reject - - - C++ - void reject(Message&); - - - .NET - public void Reject(Message __p1); - - - Method: Release - - - C++ - void release(Message&); - - - .NET - public void Release(Message __p1); - - - Method: Sync - - - C++ - void sync(bool block=true); - - - .NET - public void Sync(); - - - .NET - public void Sync(bool block); - - - Property: Receivable - - - C++ - uint32_t getReceivable(); - - - .NET - public uint Receivable { get; } - - - Property: UnsettledAcks - - - C++ - uint32_t getUnsettledAcks(); - - - .NET - public uint UnsetledAcks { get; } - - - Method: NextReceiver - - - C++ - bool nextReceiver(Receiver&, Duration timeout=Duration::FOREVER); - - - .NET - public bool NextReceiver(Receiver rcvr); - - - .NET - public bool NextReceiver(Receiver rcvr, Duration timeout); - - - Method: NextReceiver - - - C++ - Receiver nextReceiver(Duration timeout=Duration::FOREVER); - - - .NET - public Receiver NextReceiver(); - - - .NET - public Receiver NextReceiver(Duration timeout); - - - Method: CreateSender - - - C++ - Sender createSender(const Address& address); - - - .NET - public Sender CreateSender(Address address); - - - Method: CreateSender - - - C++ - Sender createSender(const std::string& address); - - - .NET - public Sender CreateSender(string address); - - - Method: CreateReceiver - - - C++ - Receiver createReceiver(const Address& address); - - - .NET - public Receiver CreateReceiver(Address address); - - - Method: CreateReceiver - - - C++ - Receiver createReceiver(const std::string& address); - - - .NET - public Receiver CreateReceiver(string address); - - - Method: GetSender - - - C++ - Sender getSender(const std::string& name) const; - - - .NET - public Sender GetSender(string name); - - - Method: GetReceiver - - - C++ - Receiver getReceiver(const std::string& name) const; - - - .NET - public Receiver GetReceiver(string name); - - - Property: Connection - - - C++ - Connection getConnection() const; - - - .NET - public Connection Connection { get; } - - - Property: HasError - - - C++ - bool hasError(); - - - .NET - public bool HasError { get; } - - - Method: CheckError - - - C++ - void checkError(); - - - .NET - public void CheckError(); - - - -
-
-
- .NET Binding Class: SessionReceiver - - The SessionReceiver class provides a convenient callback - mechanism for Messages received by all Receivers on a given - Session. - - - - - - - To use this class a client program includes references to both - Org.Apache.Qpid.Messaging and Org.Apache.Qpid.Messaging.SessionReceiver. - The calling program creates a function that implements the - ISessionReceiver interface. This function will be called whenever - message is received by the session. The callback process is started - by creating a CallbackServer and will continue to run until the - client program calls the CallbackServer.Close function. - - - A complete operating example of using the SessionReceiver callback - is contained in cpp/bindings/qpid/dotnet/examples/csharp.map.callback.receiver. - -
-
- - - - diff --git a/doc/book/src/programming/Programming-In-Apache-Qpid.xml b/doc/book/src/programming/Programming-In-Apache-Qpid.xml new file mode 100644 index 0000000000..e2f6d8756c --- /dev/null +++ b/doc/book/src/programming/Programming-In-Apache-Qpid.xml @@ -0,0 +1,6530 @@ + + + + + + + Programming in Apache Qpid + Cross-Platform AMQP Messaging in Java JMS, .NET, C++, and Python + + + Introduction + + Apache Qpid is a reliable, asynchronous messaging system that + supports the AMQP messaging protocol in several common programming + languages. Qpid is supported on most common platforms. + + + + + + On the Java platform, Qpid uses the + established Java JMS + API. + + + + + For Python, C++, and .NET, Qpid defines its own messaging API, the + Qpid Messaging API, which is + conceptually similar in each. + + + On the .NET platform, Qpid also provides a WCF binding. + + + + + Ruby will also use the Qpid Messaging API, which will soon + be implemented. (Ruby currently uses an API that is closely + tied to the AMQP version). + + + + + + + + Using the Qpid Messaging API + + The Qpid Messaging API is quite simple, consisting of only a + handful of core classes. + + + + + + + A message consists of a standard set + of fields (e.g. subject, + reply-to), an application-defined set of + properties, and message content (the main body of the + message). + + + + + + A connection represents a network + connection to a remote endpoint. + + + + + + A session provides a sequentially + ordered context for sending and receiving + messages. A session is obtained from a + connection. + + + + + + A sender sends messages to a target + using the sender.send method. A sender is + obtained from a session for a given target address. + + + + + + A receiver receives messages from a + source using the receiver.fetch method. + A receiver is obtained from a session for a given source + address. + + + + + + + The following sections show how to use these classes in a + simple messaging program. + + +
+ A Simple Messaging Program in C++ + + The following C++ program shows how to create a connection, + create a session, send messages using a sender, and receive + messages using a receiver. + + + "Hello world!" in C++ + + #include + #include + #include + #include + + #include ]]> + + using namespace qpid::messaging; + + int main(int argc, char** argv) { + std::string broker = argc > 1 ? argv[1] : "localhost:5672"; + std::string address = argc > 2 ? argv[2] : "amq.topic"; + std::string connectionOptions = argc > 3 ? argv[3] : ""; + + Connection connection(broker, connectionOptions); + try { + connection.open(); + Session session = connection.createSession(); + + Receiver receiver = session.createReceiver(address); + Sender sender = session.createSender(address); + + sender.send(Message("Hello world!")); + + Message message = receiver.fetch(Duration::SECOND * 1); + + session.acknowledge(); + + connection.close(); + return 0; + } catch(const std::exception& error) { + + connection.close(); + return 1; + } + } + + + + Establishes the connection with the messaging broker. + + + Creates a session object on which messages will be sent and received. + + + Creates a receiver that receives messages from the given address. + + + Creates a sender that sends to the given address. + + + Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. + + + Acknowledges receipt of all fetched messages on the + session. This informs the broker that the messages were + transferred and processed by the client successfully. + + + Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. + + + + + +
+ +
+ A Simple Messaging Program in Python + + The following Python program shows how to create a + connection, create a session, send messages using a sender, and + receive messages using a receiver. + + + "Hello world!" in Python + + + connection = Connection(broker) + + try: + connection.open() + session = connection.session() + + sender = session.sender(address) + receiver = session.receiver(address) + + sender.send(Message("Hello world!")); + + message = receiver.fetch(timeout=1) + print message.content + session.acknowledge() + + except MessagingError,m: + print m + finally: + connection.close() + + + + + Establishes the connection with the messaging broker. + + + Creates a session object on which messages will be sent and received. + + + Creates a receiver that receives messages from the given address. + + + Creates a sender that sends to the given address. + + + Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. + + + Acknowledges receipt of all fetched messages on + the session. This informs the broker that the messages were + transfered and processed by the client successfully. + + + Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. + + + + + +
+ + + + +
+ A Simple Messaging Program in .NET C# + + The following .NET C# + + + The .NET binding for the Qpid C++ Messaging API + applies to all .NET Framework managed code languages. C# was chosen + for illustration purposes only. + + + program shows how to create a connection, + create a session, send messages using a sender, and receive + messages using a receiver. + + + + "Hello world!" in .NET C# + + using System; + using Org.Apache.Qpid.Messaging; + + namespace Org.Apache.Qpid.Messaging { + class Program { + static void Main(string[] args) { + String broker = args.Length > 0 ? args[0] : "localhost:5672"; + String address = args.Length > 1 ? args[1] : "amq.topic"; + + Connection connection = null; + try { + connection = new Connection(broker); + connection.Open(); + Session session = connection.CreateSession(); + + Receiver receiver = session.CreateReceiver(address); + Sender sender = session.CreateSender(address); + + sender.Send(new Message("Hello world!")); + + Message message = new Message(); + message = receiver.Fetch(DurationConstants.SECOND * 1); + Console.WriteLine("{0}", message.GetContent()); + session.Acknowledge(); + + connection.Close(); + } catch (Exception e) { + Console.WriteLine("Exception {0}.", e); + if (null != connection) + connection.Close(); + } + } + } + } + + + + + + Permits use of Org.Apache.Qpid.Messaging types and methods without explicit namespace qualification. Any .NET project must have a project reference to the assembly file Org.Apache.Qpid.Messaging.dll in order to obtain the definitions of the .NET Binding for Qpid Messaging namespace. + + + Establishes the connection with the messaging broker. + + + Creates a session object on which messages will be sent and received. + + + Creates a receiver that receives messages from the given address. + + + Creates a sender that sends to the given address. + + + Receives the next message. The duration is optional, if omitted, will wait indefinitely for the next message. + + + Acknowledges receipt of all fetched messages on the + session. This informs the broker that the messages were + transfered and processed by the client successfully. + + + Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. + + + + + +
+ + + + + + +
+ Addresses + + An address is the name of a message + target or message source. + + In the programs we have just seen, we used + amq.topic as the default address if none is + passed in. This is the name of a standard exchange that always + exists on an AMQP 0-10 messaging broker. + + The methods that create senders and receivers require an + address. The details of sending to a particular target or + receiving from a particular source are then handled by the + sender or receiver. A different target or source can be used + simply by using a different address. + + + An address resolves to a node. The + Qpid Messaging API recognises two kinds of nodes, + queues and topics + + The terms queue and + topic here were chosen to align with + their meaning in JMS. These two addressing 'patterns', + queue and topic, are sometimes refered as point-to-point + and publish-subscribe. AMQP 0-10 has an exchange type + called a topic exchange. When the term + topic occurs alone, it refers to a + Messaging API topic, not the topic + exchange.. + + A queue stores each message until it has been received and + acknowledged, and only one receiver can receive a given message + + There are exceptions to this rule; for instance, + a receiver can use browse mode, which leaves + messages on the queue for other receivers to + read.. + + A topic immediately delivers a message to all eligible + receivers; if there are no eligible receivers, it discards the + message. In the AMQP 0-10 implementation of the API, + + The AMQP 0-10 implementation is the only one + that currently exists. + + queues map to AMQP queues, and topics map to AMQP exchanges. + + In AMQP 0-10, messages are sent to + exchanges, and read from queues. The Messaging API also + allows a sender to send messages to a queue; internally, + Qpid implements this by sending the message to the default + exchange, with the name of the queue as the routing key. The + Messaging API also allows a receiver to receive messages + from a topic; internally, Qpid implements this by setting up + a private subscription queue for the receiver and binding + the subscription queue to the exchange that corresponds to + the topic. + + + In the rest of this tutorial, we present many examples + using two programs that take an address as a command line + parameter. spout sends messages to the + target address, drain receives messages from + the source address. The source code is available in C++, Python, and + .NET C# and can be found in the examples directory for each + language. These programs can use any address string as a source + or a destination, and have many command line options to + configure behavior—use the -h option + for documentation on these options. + + Currently, the C++, Python, and .NET C# + implementations of drain and + spout have slightly different + options. This tutorial uses the C++ implementation. The + options will be reconciled in the near + future. + + + The examples in this tutorial also use the + qpid-config utility to configure AMQP 0-10 + queues and exchanges on a Qpid broker. + + + + + Queues + + Create a queue with qpid-config, send a message using + spout, and read it using drain: + + + $ qpid-config add queue hello-world + $ ./spout hello-world + $ ./drain hello-world + + Message(properties={spout-id:c877e622-d57b-4df2-bf3e-6014c68da0ea:0}, content='') + + + The queue stored the message sent by spout and delivered + it to drain when requested. + + Once the message has been delivered and and acknowledged + by drain, it is no longer available on the queue. If we run + drain one more time, no messages will be retrieved. + + + $ ./drain hello-world + $ + + + + + + Topics + + This example is similar to the previous example, but it + uses a topic instead of a queue. + + First, use qpid-config to remove the queue + and create an exchange with the same name: + + + $ qpid-config del queue hello-world + $ qpid-config add exchange topic hello-world + + + Now run drain and spout the same way we did in the previous example: + + + $ ./spout hello-world + $ ./drain hello-world + $ + + + Topics deliver messages immediately to any interested + receiver, and do not store messages. Because there were no + receivers at the time spout sent the + message, it was simply discarded. When we ran + drain, there were no messages to + receive. + + Now let's run drain first, using the + -t option to specify a timeout in seconds. + While drain is waiting for messages, + run spout in another window. + + First Window: + + + $ ./drain -t 30 hello-word + + + + Second Window: + + + $ ./spout hello-word + + + Once spout has sent a message, return + to the first window to see the output from + drain: + + + Message(properties={spout-id:7da2d27d-93e6-4803-8a61-536d87b8d93f:0}, content='') + + + You can run drain in several separate + windows; each creates a subscription for the exchange, and + each receives all messages sent to the exchange. + + + +
+ Address Strings + + So far, our examples have used address strings that + contain only the name of a node. An address + string can also contain a + subject and + options. + + The syntax for an address string is: + + [ / ] [ ; ] + options ::= { : , ... } + ]]> + + Addresses, subjects, and keys are strings. Values can + be numbers, strings (with optional single or double quotes), + maps, or lists. A complete BNF for address strings appears in + . + + + So far, the address strings in this tutorial have only + used simple names. The following sections show how to use + subjects and options. + +
+ +
+ Subjects + + + Every message has a property called + subject, which is analogous to the + subject on an email message. If no subject is specified, the + message's subject is null. For convenience, address strings + also allow a subject. If a sender's address contains a + subject, it is used as the default subject for the messages + it sends. + + If a receiver's address contains a subject, it is used to + select only messages that match the subject—the matching + algorithm depends on the message source. + + + + In AMQP 0-10, each exchange type has its own matching + algorithm. This is discussed in + . + + + + + Currently, a receiver bound to a queue ignores subjects, + receiving messages from the queue without filtering. Support + for subject filtering on queues will be implemented soon. + + + + + + Using subjects + + In this example we show how subjects affect message + flow. + + First, let's use qpid-config to create a topic exchange. + + + $ qpid-config add exchange topic news-service + + + Now we use drain to receive messages from news-service that match the subject sports. + First Window: + + $ ./drain -t 30 news-service/sports + + + In a second window, let's send messages to news-service using two different subjects: + + Second Window: + + $ ./spout news-service/sports + $ ./spout news-service/news + + + Now look at the first window, the message with the + subject sports has been received, but not + the message with the subject news: + + + Message(properties={qpid.subject:sports, spout-id:9441674e-a157-4780-a78e-f7ccea998291:0}, content='') + + + If you run drain in multiple + windows using the same subject, all instances of + drain receive the messages for that + subject. + + + + The AMQP exchange type we are using here, + amq.topic, can also do more sophisticated + matching. + + A sender's subject can contain multiple words separated by a + . delimiter. For instance, in a news + application, the sender might use subjects like + usa.news, usa.weather, + europe.news, or + europe.weather. + + The receiver's subject can include wildcard characters— + # matches one or more words in the message's + subject, * matches a single word. + + For instance, if the subject in the source address is + *.news, it matches messages with the + subject europe.news or + usa.news; if it is + europe.#, it matches messages with subjects + like europe.news or + europe.pseudo.news. + + + Subjects with multi-word keys + + This example uses drain and spout to demonstrate the + use of subjects with two-word keys. + + Let's use drain with the subject + *.news to listen for messages in which + the second word of the key is + news. + + First Window: + + + $ ./drain -t 30 news-service/*.news + + + Now let's send messages using several different + two-word keys: + + Second Window: + + + $ ./spout news-service/usa.news + $ ./spout news-service/usa.sports + $ ./spout news-service/europe.sports + $ ./spout news-service/europe.news + + + In the first window, the messages with + news in the second word of the key have + been received: + + + Message(properties={qpid.subject:usa.news, spout-id:73fc8058-5af6-407c-9166-b49a9076097a:0}, content='') + Message(properties={qpid.subject:europe.news, spout-id:f72815aa-7be4-4944-99fd-c64c9747a876:0}, content='') + + + + Next, let's use drain with the + subject #.news to match any sequence of + words that ends with news. + + First Window: + + + $ ./drain -t 30 news-service/#.news + + + In the second window, let's send messages using a + variety of different multi-word keys: + + Second Window: + + + $ ./spout news-service/news + $ ./spout news-service/sports + $ ./spout news-service/usa.news + $ ./spout news-service/usa.sports + $ ./spout news-service/usa.faux.news + $ ./spout news-service/usa.faux.sports + + + In the first window, messages with + news in the last word of the key have been + received: + + + Message(properties={qpid.subject:news, spout-id:cbd42b0f-c87b-4088-8206-26d7627c9640:0}, content='') + Message(properties={qpid.subject:usa.news, spout-id:234a78d7-daeb-4826-90e1-1c6540781eac:0}, content='') + Message(properties={qpid.subject:usa.faux.news, spout-id:6029430a-cfcb-4700-8e9b-cbe4a81fca5f:0}, content='') + + + +
+ +
+ Address String Options + + + The options in an address string can contain additional + information for the senders or receivers created for it, + including: + + + + + Policies for assertions about the node to which an address + refers. + + + For instance, in the address string my-queue; + {assert: always, node:{ type: queue }}, the node + named my-queue must be a queue; if not, + the address does not resolve to a node, and an exception + is raised. + + + + + Policies for automatically creating or deleting the node to which an address refers. + + + For instance, in the address string xoxox ; {create: always}, + the queue xoxox is created, if it does + not exist, before the address is resolved. + + + + + Extension points that can be used for sender/receiver configuration. + + + For instance, if the address for a receiver is + my-queue; {mode: browse}, the receiver + works in browse mode, leaving messages + on the queue so other receivers can receive them. + + + + + Extension points providing more direct control over the underlying protocol. + + + For instance, the x-bindings property + allows greater control over the AMQP 0-10 binding process + when an address is resolved. + + + + + + + Let's use some examples to show how these different kinds of + address string options affect the behavior of senders and + receives. + + +
+ assert + + In this section, we use the assert option + to ensure that the address resolves to a node of the required + type. + + + + + Assertions on Nodes + + Let's use qpid-config to create a + queue and a topic. + + + $ qpid-config add queue my-queue + $ qpid-config add exchange topic my-topic + + + + We can now use the address specified to drain to assert that it is + of a particular type: + + + + $ ./drain 'my-queue; {assert: always, node:{ type: queue }}' + $ ./drain 'my-queue; {assert: always, node:{ type: topic }}' + 2010-04-20 17:30:46 warning Exception received from broker: not-found: not-found: Exchange not found: my-queue (../../src/qpid/broker/ExchangeRegistry.cpp:92) [caused by 2 \x07:\x01] + Exchange my-queue does not exist + + + + The first attempt passed without error as my-queue is indeed a + queue. The second attempt however failed; my-queue is not a + topic. + + + + We can do the same thing for my-topic: + + + + $ ./drain 'my-topic; {assert: always, node:{ type: topic }}' + $ ./drain 'my-topic; {assert: always, node:{ type: queue }}' + 2010-04-20 17:31:01 warning Exception received from broker: not-found: not-found: Queue not found: my-topic (../../src/qpid/broker/SessionAdapter.cpp:754) [caused by 1 \x08:\x01] + Queue my-topic does not exist + + + + Now let's use the create option to + create the queue xoxox if it does not already + exist: + +
+ +
+ create + + In previous examples, we created the queue before + listening for messages on it. Using create: + always, the queue is automatically created if it + does not exist. + + + Creating a Queue Automatically + + First Window: + $ ./drain -t 30 "xoxox ; {create: always}" + + + Now we can send messages to this queue: + + Second Window: + $ ./spout "xoxox ; {create: always}" + + Returning to the first window, we see that drain has received this message: + + Message(properties={spout-id:1a1a3842-1a8b-4f88-8940-b4096e615a7d:0}, content='') + + The details of the node thus created can be controlled by further options within the node. See for details. +
+ +
+ browse + Some options specify message transfer semantics; for + instance, they may state whether messages should be consumed or + read in browsing mode, or specify reliability + characteristics. The following example uses the + browse option to receive messages without + removing them from a queue. + + + Browsing a Queue + + Let's use the browse mode to receive messages without + removing them from the queue. First we send three messages to the + queue: + + + $ ./spout my-queue --content one + $ ./spout my-queue --content two + $ ./spout my-queue --content three + + + Now we use drain to get those messages, using the browse option: + + $ ./drain 'my-queue; {mode: browse}' + Message(properties={spout-id:fbb93f30-0e82-4b6d-8c1d-be60eb132530:0}, content='one') + Message(properties={spout-id:ab9e7c31-19b0-4455-8976-34abe83edc5f:0}, content='two') + Message(properties={spout-id:ea75d64d-ea37-47f9-96a9-d38e01c97925:0}, content='three') + + + We can confirm the messages are still on the queue by repeating the drain: + + $ ./drain 'my-queue; {mode: browse}' + Message(properties={spout-id:fbb93f30-0e82-4b6d-8c1d-be60eb132530:0}, content='one') + Message(properties={spout-id:ab9e7c31-19b0-4455-8976-34abe83edc5f:0}, content='two') + Message(properties={spout-id:ea75d64d-ea37-47f9-96a9-d38e01c97925:0}, content='three') + + +
+ +
+ x-bindings + + Greater control over the AMQP 0-10 binding process can + be achieved by including an x-bindings + option in an address string. + + For instance, the XML Exchange is an AMQP 0-10 custom exchange + provided by the Apache Qpid C++ broker. It allows messages to + be filtered using XQuery; queries can address either message + properties or XML content in the body of the message. The + xquery is specified in the arguments field of the AMQP 0-10 + command. When using the messaging API an xquery can be + specified in and address that resolves to an XML exchange by + using the x-bindings property. + + + An instance of the XML Exchange must be added before it + can be used: + + + $ qpid-config add exchange xml xml + + + When using the XML Exchange, a receiver provides an + XQuery as an x-binding argument. If the query contains a + context item (a path starting with .), then it + is applied to the content of the message, which must be + well-formed XML. For instance, ./weather is + a valid XQuery, which matches any message in which the root + element is named weather. Here is an + address string that contains this query: + + + + When using longer queries with drain, + it is often useful to place the query in a file, and use + cat in the command line. We do this in the + following example. + + + Using the XML Exchange + + This example uses an x-binding that contains queries, which filter based on the content of XML messages. Here is an XQuery that we will use in this example: + + + 50 + and $w/temperature_f - $w/dewpoint > 5 + and $w/wind_speed_mph > 7 + and $w/wind_speed_mph < 20 ]]> + + + We can specify this query in an x-binding to listen to messages that meet the criteria specified by the query: + + First Window: + + + $ ./drain -f "xml; {link:{x-bindings:[{key:'weather', + arguments:{xquery:\"$(cat rdu.xquery )\"}}]}}" + + + In another window, let's create an XML message that meets the criteria in the query, and place it in the file rdu.xml: + + + + Raleigh-Durham International Airport (KRDU) + 16 + 70 + 35 + + ]]> + + Now let's use spout to send this message to the XML exchange: + + Second Window: + + spout --content "$(cat rdu.xml)" xml/weather + + + Returning to the first window, we see that the message has been received: + + + Raleigh-Durham International Airport (KRDU) + 16 + 40 + 35 + ') ]]> + + +
+ + + + + +
+ Address String Options - Reference + + + Address String Options + + + + + + + option + value + semantics + + + + + + assert + + + one of: always, never, sender or receiver + + + Asserts that the properties specified in the node option + match whatever the address resolves to. If they do not, + resolution fails and an exception is raised. + + + + + + create + + + one of: always, never, sender or receiver + + + Creates the node to which an address refers if it does + not exist. No error is raised if the node does + exist. The details of the node may be specified in the + node option. + + + + + delete + + + one of: always, never, sender or receiver + + + Delete the node when the sender or receiver is closed. + + + + + node + + + A nested map containing the entries shown in . + + + Specifies properties of the node to which the address + refers. These are used in conjunction with the assert or + create options. + + + + + link + + + A nested map containing the entries shown in . + + + Used to control the establishment of a conceptual link + from the client application to or from the target/source + address. + + + + + mode + + + one of: browse, consume + + + This option is only of relevance for source addresses + that resolve to a queue. If browse is specified the + messages delivered to the receiver are left on the queue + rather than being removed. If consume is specified the + normal behaviour applies; messages are removed from the + queue once the client acknowledges their receipt. + + + + +
+ + + + Node Properties + + + + + + + property + value + semantics + + + + + + type + + + topic, queue + + + Indicates the type of the node. + + + + + durable + + + True, False + + + Indicates whether the node survives a loss of + volatile storage e.g. if the broker is restarted. + + + + + x-declare + + + A nested map whose values correspond to the valid fields + on an AMQP 0-10 queue-declare or exchange-declare + command. + + + These values are used to fine tune the creation or + assertion process. Note however that they are protocol + specific. + + + + + x-bindings + + + A nested list in which each binding is represented by + a map. The entries of the map for a binding contain + the fields that describe an AMQP 0-10 binding. Here is + the format for x-bindings: + + , + queue: , + key: , + arguments: { + : , + ..., + : } + }, + ... + ] + ]]> + + + In conjunction with the create option, each of these + bindings is established as the address is resolved. In + conjunction with the assert option, the existence of + each of these bindings is verified during + resolution. Again, these are protocol specific. + + + + +
+ + + Link Properties + + + + + + + option + value + semantics + + + + + + reliability + + + one of: unreliable, at-least-once, at-most-once, exactly-once + + + Reliability indicates the level of reliability that + the sender or receiver. unreliable + and at-most-once are currently + treated as synonyms, and allow messages to be lost if + a broker crashes or the connection to a broker is + lost. at-least-once guarantees that + a message is not lost, but duplicates may be + received. exactly-once guarantees + that a message is not lost, and is delivered precisely + once. Currently only unreliable + and at-least-once are supported. + If at-most-once is requested, + unreliable will be used and for durable messages on + durable queues there is the possibility that messages + will be redelivered; if exactly-once is requested, + at-least-once will be used and the application needs to + be able to deal with duplicates. + + + + + durable + + + True, False + + + Indicates whether the link survives a loss of + volatile storage e.g. if the broker is restarted. + + + + + x-declare + + + A nested map whose values correspond to the valid fields + of an AMQP 0-10 queue-declare command. + + + These values can be used to customise the subscription + queue in the case of receiving from an exchange. Note + however that they are protocol specific. + + + + + x-subscribe + + + A nested map whose values correspond to the valid fields + of an AMQP 0-10 message-subscribe command. + + + These values can be used to customise the subscription. + + + + + x-bindings + + + A nested list each of whose entries is a map that may + contain fields (queue, exchange, key and arguments) + describing an AMQP 0-10 binding. + + + These bindings are established during resolution + independent of the create option. They are considered + logically part of the linking process rather than of + node creation. + + + + + + +
+
+ +
+ Address String Grammar + + This section provides a formal grammar for address strings. + + + Tokens + The following regular expressions define the tokens used + to parse address strings: + + + + Grammar + The formal grammar for addresses is given below: + + + + + + + Address String Options + The address string options map supports the following parameters: + + + [ / ] ; { + create: always | sender | receiver | never, + delete: always | sender | receiver | never, + assert: always | sender | receiver | never, + mode: browse | consume, + node: { + type: queue | topic, + durable: True | False, + x-declare: { ... ... }, + x-bindings: [, ... ] + }, + link: { + name: , + durable: True | False, + reliability: unreliable | at-most-once | at-least-once | exactly-once, + x-declare: { ... ... }, + x-bindings: [, ... ], + x-subscribe: { ... ... } + } + } + ]]> + + + + Create, Delete, and Assert Policies + The create, delete, and assert policies specify who should + perfom the associated action: + always: the action is performed by any messaging client + sender: the action is only performed by a sender + receiver: the action is only performed by a receiver + never: the action is never performed (this is the default) + + + + Node-Type + The node-type is one of: + topic: in the AMQP 0-10 + mapping, a topic node defaults to the topic exchange, x-declare + may be used to specify other exchange types + queue: this is the default node-type + +
+ + +
+ +
+ Sender Capacity and Replay + + The send method of a sender has an optional second parameter + that controls whether the send call is synchronous or not. A + synchronous send call will block until the broker has confirmed + receipt of the message. An asynchronous send call will return + before the broker confirms receipt of the message, allowing for + example further send calls to be made without waiting for a + roundtrip to the broker for each message. This is desirable where + increased throughput is important. + + The sender maintains a list of sent messages whose receipt + has yet to be confirmed by the broker. The maximum number of such + messages that it will hold is defined by the capacity of the + sender, which can be set by the application. If an application + tries to send with a sender whose capacity is already fully used + up, the send call will block waiting for capacity regardless of + the value of the sync flag. + + The sender can be queried for the available space (i.e. the + unused capacity), and for the current count of unsettled messages + (i.e. those held in the replay list pending confirmation by the + server). When the unsettled count is zero, all messages on that + sender have been successfully sent. + + If the connection fails and is transparently reconnected + (see for details on how to control + this feature), the unsettled messages for each sender over that + connection will be re-transmitted. This provides a transparent + level of reliability. This feature can be controlled through the + link's reliability as defined in the address (see + ). At present only + at-least-once guarantees are offered. +
+ +
+ Receiver Capacity (Prefetch) + + By default, a receiver requests the next message from the + server in response to each fetch call, resulting in messages being + sent to the receiver one at a time. As in the case of sending, it + is often desirable to avoid this roundtrip for each message. This + can be achieved by allowing the receiver + to prefetch messages in anticipation of + fetch calls being made. The receiver needs to be able to store + these prefetched messages, the number it can hold is controlled by + the receivers capacity. + +
+ +
+ Acknowledging Received Messages + + Applications that receive messages should acknowledge their + receipt by calling the session's acknowledge method. As in the + case of sending messages, acknowledged transfer of messages to + receivers provides at-least-once reliability, which means that the + loss of the connection or a client crash does not result in lost + messages; durable messages are not lost even if the broker is + restarted. + + Some cases may not require this however and the reliability can be + controlled through a link property in the address options (see + ). + + The acknowledge call acknowledges all messages received on + the session (i.e. all message that have been returned from a fetch + call on a receiver created on that session). + + The acknowledge call also support an optional parameter + controlling whether the call is synchronous or not. A synchronous + acknowledge will block until the server has confirmed that it has + received the acknowledgement. In the asynchronous case, when the + call returns there is not yet any guarantee that the server has + received and processed the acknowledgement. The session may be + queried for the number of unsettled acknowledgements; when that + count is zero all acknowledgements made for received messages have + been successful. + +
+ + +
+ Receiving Messages from Multiple Sources + + A receiver can only read from one source, but many + programs need to be able to read messages from many sources. In + the Qpid Messaging API, a program can ask a session for + the next receiver; that is, the receiver that is + responsible for the next available message. The following + examples show how this is done in C++, Python, and .NET C#. + + + Note that to use this pattern you must enable prefetching + for each receiver of interest so that the broker will send + messages before a fetch call is made. See + for more on this. + + + Receiving Messages from Multiple Sources + + C++: + + + + Python: + + + .NET C#: + + + +
+ +
+ Transactions + + Sometimes it is useful to be able to group messages + transfers - sent and/or received - on a session into atomic + grouping. This can be done be creating the session as + transactional. On a transactional session sent messages only + become available at the target address on commit. Likewise any + received and acknowledged messages are only discarded at their + source on commit + + Note that this currently is only true for + messages received using a reliable mode + e.g. at-least-once. Messages sent by a broker to a receiver in + unreliable receiver will be discarded immediately regardless of + transctionality. + + . + + + Transactions + C++: + + + .NET C#: + + + + Connection connection = new Connection(broker); + Session session = connection.CreateTransactionalSession(); + ... + if (smellsOk()) + session.Commit(); + else + session.Rollback(); + + + + +
+ +
+ Connection Options + + + Aspects of the connections behaviour can be controlled through + specifying connection options. For example, connections can be + configured to automatically reconnect if the connection to a + broker is lost. + + + + Specifying Connection Options in C++, Python, and .NET + + In C++, these options can be set using Connection::setOption() or by passing in a set of options to the constructor. The options can be passed in as a map or in string form: + + + + or + + + + In Python, these options can be set as attributes of the connection or using named arguments in + the Connection constructor: + + + + or + + + + In .NET, these options can be set using Connection.SetOption() or by passing in a set of options to the constructor. The options can be passed in as a map or in string form: + + + + Connection connection= new Connection("localhost:5672", "{reconnect: true}"); + try { + connection.Open(); + !!! SNIP !!! + + + or + + + + Connection connection = new Connection("localhost:5672"); + connection.SetOption("reconnect", true); + try { + connection.Open(); + !!! SNIP !!! + + + See the reference documentation for details in each language. + + + The following table lists the supported connection options. + + + Connection Options + + + + + + + option name + value type + semantics + + + + + + + username + + + string + + + The username to use when authenticating to the broker. + + + + + password + + + string + + + The password to use when authenticating to the broker. + + + + + sasl_mechanisms + + + string + + + The specific SASL mechanisms to use with the python + client when authenticating to the broker. The value + is a space separated list. + + + + + + + reconnect + + + boolean + + + Transparently reconnect if the connection is lost. + + + + + reconnect_timeout + + + integer + + + Total number of seconds to continue reconnection attempts before giving up and raising an exception. + + + + + reconnect_limit + + + integer + + + Maximum number of reconnection attempts before giving up and raising an exception. + + + + + reconnect_interval_min + + + integer representing time in seconds + + + Minimum number of seconds between reconnection attempts. The first reconnection attempt is made immediately; if that fails, the first reconnection delay is set to the value of reconnect_interval_min; if that attempt fails, the reconnect interval increases exponentially until a reconnection attempt succeeds or reconnect_interval_max is reached. + + + + + reconnect_interval_max + + + integer representing time in seconds + + + Maximum reconnect interval. + + + + + reconnect_interval + + + integer representing time in seconds + + + Sets both reconnection_interval_min and reconnection_interval_max to the same value. + + + + + + heartbeat + + + integer representing time in seconds + + + Requests that heartbeats be sent every N seconds. If two + successive heartbeats are missed the connection is + considered to be lost. + + + + + protocol + + + string + + + Sets the underlying protocol used. The default option is 'tcp'. To enable ssl, set to 'ssl'. The C++ client additionally supports 'rdma'. + + + + + tcp-nodelay + + + boolean + + + Set tcp no-delay, i.e. disable Nagle algorithm. [C++ only] + + + + +
+ +
+ +
+ Maps and Lists in Message Content + + Many messaging applications need to exchange data across + languages and platforms, using the native datatypes of each + programming language. + + The Qpid Messaging API supports map and list in message content. + + Unlike JMS, there is not a specific message type for + map messages. + + + + Note that the Qpid JMS client supports MapMessages whose values can be nested maps or lists. This is not standard JMS behaviour. + + + Specific language support for map and list objects are shown in the following table. + + + Map and List Representation in Supported Languages + + + + Language + map + list + + + + + Python + dict + list + + + C++ + Variant::Map + Variant::List + + + Java + MapMessage +   + + + .NET + Dictionary<string, object> + Collection<object> + + + +
+ + In all languages, messages are encoded using AMQP's portable datatypes. + + + + Because of the differences in type systems among + languages, the simplest way to provide portable messages is to + rely on maps, lists, strings, 64 bit signed integers, and + doubles for messages that need to be exchanged across languages + and platforms. + + +
+ Qpid Maps and Lists in Python + + In Python, Qpid supports the dict and list types directly in message content. The following code shows how to send these structures in a message: + + + Sending Qpid Maps and Lists in Python + + + + + The following table shows the datatypes that can be sent in a Python map message, + and the corresponding datatypes that will be received by clients in Java or C++. + + + + Python Datatypes in Maps + + + + Python Datatype + → C++ + → Java + + + + boolboolboolean + intint64long + longint64long + floatdoubledouble + unicodestringjava.lang.String + uuidqpid::types::Uuidjava.util.UUID + dictVariant::Mapjava.util.Map + listVariant::Listjava.util.List + + +
+ +
+ + + + +
+ Qpid Maps and Lists in C++ + + + In C++, Qpid defines the the + Variant::Map and + Variant::List types, which can be + encoded into message content. The following code shows how to + send these structures in a message: + + + Sending Qpid Maps and Lists in C++ + + + + The following table shows the datatypes that can be sent + in a C++ map message, and the corresponding datatypes that + will be received by clients in Java and Python. + + + C++ Datatypes in Maps + + + + C++ Datatype + → Python + → Java + + + + boolboolboolean + uint16int | longshort + uint32int | longint + uint64int | longlong + int16int | longshort + int32int | longint + int64int | longlong + floatfloatfloat + doublefloatdouble + stringunicodejava.lang.String + qpid::types::Uuiduuidjava.util.UUID + Variant::Mapdictjava.util.Map + Variant::Listlistjava.util.List + + +
+
+ +
+ Qpid Maps and Lists in .NET + + + + The .NET binding for the Qpid Messaging API binds .NET managed data types + to C++ Variant data types. The following code shows how to + send Map and List structures in a message: + + + + + Sending Qpid Maps and Lists in .NET C# + content = new Dictionary(); + Dictionary subMap = new Dictionary(); + Collection colors = new Collection(); + + // add simple types + content["id"] = 987654321; + content["name"] = "Widget"; + content["percent"] = 0.99; + + // add nested amqp/map + subMap["name"] = "Smith"; + subMap["number"] = 354; + content["nestedMap"] = subMap; + + // add an amqp/list + colors.Add("red"); + colors.Add("green"); + colors.Add("white"); + content["colorsList"] = colors; + + // add one of each supported amqp data type + bool mybool = true; + content["mybool"] = mybool; + + byte mybyte = 4; + content["mybyte"] = mybyte; + + UInt16 myUInt16 = 5; + content["myUInt16"] = myUInt16; + + UInt32 myUInt32 = 6; + content["myUInt32"] = myUInt32; + + UInt64 myUInt64 = 7; + content["myUInt64"] = myUInt64; + + char mychar = 'h'; + content["mychar"] = mychar; + + Int16 myInt16 = 9; + content["myInt16"] = myInt16; + + Int32 myInt32 = 10; + content["myInt32"] = myInt32; + + Int64 myInt64 = 11; + content["myInt64"] = myInt64; + + Single mySingle = (Single)12.12; + content["mySingle"] = mySingle; + + Double myDouble = 13.13; + content["myDouble"] = myDouble; + + Guid myGuid = new Guid("000102030405060708090a0b0c0d0e0f"); + content["myGuid"] = myGuid; + + Message message = new Message(content); + Send(message, true); + ]]> + + + + The following table shows the mapping between datatypes in .NET and C++. + + + + Datatype Mapping between C++ and .NET binding + + + + C++ Datatype + → .NET binding + + + + voidnullptr + boolbool + uint8byte + uint16UInt16 + uint32UInt32 + uint64UInt64 + uint8char + int16Int16 + int32Int32 + int64Int64 + floatSingle + doubleDouble + stringstring + + Strings are currently interpreted only with UTF-8 encoding. + + qpid::types::UuidGuid + Variant::Map]]> + + Variant::List]]> + + + +
+ + + + + + + +
+ The Request / Response Pattern + Request / Response applications use the reply-to property, + described in , to allow a server + to respond to the client that sent a message. A server sets up a + service queue, with a name known to clients. A client creates a + private queue for the server's response, creates a message for a + request, sets the request's reply-to property to the address of + the client's response queue, and sends the request to the + service queue. The server sends the response to the address + specified in the request's reply-to property. + + + Request / Response Applications in C++ + + This example shows the C++ code for a client and server + that use the request / response pattern. + + The server creates a service queue and waits for a + message to arrive. If it receives a message, it sends a + message back to the sender. + + + + The client creates a sender for the service queue, and + also creates a response queue that is deleted when the + client closes the receiver for the response queue. In the C++ + client, if the address starts with the character + #, it is given a unique name. + + " << response.getContent() << std::endl; + ]]> + + The client sends the string ping to + the server. The server sends the response + pong back to the same client, using the + replyTo property. + + + +
+ + +
+ Performance Tips + + + + Consider prefetching messages for receivers (see + ). This helps eliminate roundtrips + and increases throughput. Prefetch is disabled by default, + and enabling it is the most effective means of improving + throughput of received messages. + + + Send messages asynchronously. Again, this helps + eliminate roundtrips and increases throughput. The C++ and + .NET clients send asynchronously by default, however the + python client defaults to synchronous sends. + + + Acknowledge messages in batches (see + ). Rather than + acknowledging each message individually, consider issuing + acknowledgements after n messages and/or after a particular + duration has elapsed. + + + Tune the sender capacity (see + ). If the capacity is too low the + sender may block waiting for the broker to confirm receipt + of messages, before it can free up more capacity. + + + If you are setting a reply-to address on messages + being sent by the c++ client, make sure the address type is + set to either queue or topic as appropriate. This avoids the + client having to determine which type of node is being + refered to, which is required when hanling reply-to in AMQP + 0-10. + + + For latency sensitive applications, setting tcp-nodelay + on qpidd and on client connections can help reduce the + latency. + + +
+ +
+ Cluster Failover + + The messaging broker can be run in clustering mode, which provides high reliability through replicating state between brokers in the cluster. If one broker in a cluster fails, clients can choose another broker in the cluster and continue their work. Each broker in the cluster also advertises the addresses of all known brokers + + This is done via the amq.failover exchange in AMQP 0-10 + + . A client can use this information to dynamically keep the list of reconnection urls up to date. + + In C++, the FailoverUpdates class provides this functionality: + + + Tracking cluster membership + + In C++: + + + ... + Connection connection("localhost:5672"); + connection.setOption("reconnect", true); + try { + connection.open(); + std::auto_ptr updates(new FailoverUpdates(connection)); + ]]> + + + In python: + + + + + In .NET C#: + + + + using Org.Apache.Qpid.Messaging; + ... + connection = new Connection("localhost:5672"); + connection.SetOption("reconnect", true); + try { + connection.Open(); + FailoverUpdates failover = new FailoverUpdates(connection); + + + + + +
+ + + +
+ Logging + + To simplify debugging, Qpid provides a logging facility + that prints out messaging events. + +
+ Logging in C++ + + The Qpidd broker and C++ clients can both use environment variables to enable logging. Linux and Windows systems use the same named environment variables and values. + + Use QPID_LOG_ENABLE to set the level of logging you are interested in (trace, debug, info, notice, warning, error, or critical): + + + + export QPID_LOG_ENABLE="warning+" + + + The Qpidd broker and C++ clients use QPID_LOG_OUTPUT to determine where logging output should be sent. This is either a file name or the special values stderr, stdout, or syslog: + + + + export QPID_LOG_TO_FILE="/tmp/myclient.out" + + + + From a Windows command prompt, use the following command format to set the environment variables: + + + + set QPID_LOG_ENABLE=warning+ + set QPID_LOG_TO_FILE=D:\tmp\myclient.out + +
+ +
+ Logging in Python + + The Python client library supports logging using the standard Python logging module. The easiest way to do logging is to use the basicConfig(), which reports all warnings and errors: + + + from logging import basicConfig + basicConfig() + + + Qpidd also provides a convenience method that makes it easy to specify the level of logging desired. For instance, the following code enables logging at the DEBUG level: + + + from qpid.log import enable, DEBUG + enable("qpid.messaging.io", DEBUG) + + + For more information on Python logging, see http://docs.python.org/lib/node425.html. For more information on Qpid logging, use $ pydoc qpid.log. + +
+
+ + + +
+ The AMQP 0-10 mapping + + + This section describes the AMQP 0-10 mapping for the Qpid + Messaging API. + + + The interaction with the broker triggered by creating a sender + or receiver depends on what the specified address resolves + to. Where the node type is not specified in the address, the + client queries the broker to determine whether it refers to a + queue or an exchange. + + + When sending to a queue, the queue's name is set as the + routing key and the message is transfered to the default (or + nameless) exchange. When sending to an exchange, the message + is transfered to that exchange and the routing key is set to + the message subject if one is specified. A default subject may + be specified in the target address. The subject may also be + set on each message individually to override the default if + required. In each case any specified subject is also added as + a qpid.subject entry in the application-headers field of the + message-properties. + + + When receiving from a queue, any subject in the source address + is currently ignored. The client sends a message-subscribe + request for the queue in question. The accept-mode is + determined by the reliability option in the link properties; + for unreliable links the accept-mode is none, for reliable + links it is explicit. The default for a queue is reliable. The + acquire-mode is determined by the value of the mode option. If + the mode is set to browse the acquire mode is not-acquired, + otherwise it is set to pre-acquired. The exclusive and + arguments fields in the message-subscribe command can be + controlled using the x-subscribe map. + + + When receiving from an exchange, the client creates a + subscription queue and binds that to the exchange. The + subscription queue's arguments can be specified using the + x-declare map within the link properties. The reliability + option determines most of the other parameters. If the + reliability is set to unreliable then an auto-deleted, + exclusive queue is used meaning that if the client or + connection fails messages may be lost. For exactly-once the + queue is not set to be auto-deleted. The durability of the + subscription queue is determined by the durable option in the + link properties. The binding process depends on the type of + the exchange the source address resolves to. + + + + + + For a topic exchange, if no subject is specified and no + x-bindings are defined for the link, the subscription + queue is bound using a wildcard matching any routing key + (thus satisfying the expectation that any message sent to + that address will be received from it). If a subject is + specified in the source address however, it is used for + the binding key (this means that the subject in the source + address may be a binding pattern including wildcards). + + + + + For a fanout exchange the binding key is irrelevant to + matching. A receiver created from a source address that + resolves to a fanout exchange receives all messages + sent to that exchange regardless of any subject the source + address may contain. An x-bindings element in the link + properties should be used if there is any need to set the + arguments to the bind. + + + + + For a direct exchange, the subject is used as the binding + key. If no subject is specified an empty string is used as + the binding key. + + + + + For a headers exchange, if no subject is specified the + binding arguments simply contain an x-match entry and no + other entries, causing all messages to match. If a subject + is specified then the binding arguments contain an x-match + entry set to all and an entry for qpid.subject whose value + is the subject in the source address (this means the + subject in the source address must match the message + subject exactly). For more control the x-bindings element + in the link properties must be used. + + + + + For the XML exchange,Note that the XML + exchange is not a standard AMQP exchange type. It is a + Qpid extension and is currently only supported by the C++ + broker. if a subject is specified it is + used as the binding key and an XQuery is defined that + matches any message with that value for + qpid.subject. Again this means that only messages whose + subject exactly match that specified in the source address + are received. If no subject is specified then the empty + string is used as the binding key with an xquery that will + match any message (this means that only messages with an + empty string as the routing key will be received). For more + control the x-bindings element in the link properties must + be used. A source address that resolves to the XML + exchange must contain either a subject or an x-bindings + element in the link properties as there is no way at + present to receive any message regardless of routing key. + + + + + + If an x-bindings list is present in the link options a binding + is created for each element within that list. Each element is + a nested map that may contain values named queue, exchange, + key or arguments. If the queue value is absent the queue name + the address resolves to is implied. If the exchange value is + absent the exchange name the address resolves to is implied. + + + The following table shows how Qpid Messaging API message + properties are mapped to AMQP 0-10 message properties and + delivery properties. In this table msg + refers to the Message class defined in the Qpid Messaging API, + mp refers to an AMQP 0-10 + message-properties struct, and + dp refers to an AMQP 0-10 + delivery-properties struct. + + + Mapping to AMQP 0-10 Message Properties + + + + + + + Python API + C++ API + + + The .NET Binding for C++ Messaging provides all the + message and delivery properties described in the C++ API. + See . + + + + AMQP 0-10 PropertyIn these entries, mp refers to an AMQP message property, and dp refers to an AMQP delivery property. + + + + + msg.idmsg.{get,set}MessageId()mp.message_id + + + msg.subjectmsg.{get,set}Subject()mp.application_headers["qpid.subject"] + + + msg.user_idmsg.{get,set}UserId()mp.user_id + + + msg.reply_tomsg.{get,set}ReplyTo()mp.reply_toThe reply_to is converted from the protocol representation into an address. + + + msg.correlation_idmsg.{get,set}CorrelationId()mp.correlation_id + + + msg.durablemsg.{get,set}Durable()dp.delivery_mode == delivery_mode.persistentNote that msg.durable is a boolean, not an enum. + + + msg.prioritymsg.{get,set}Priority()dp.priority + + + msg.ttlmsg.{get,set}Ttl()dp.ttl + + + msg.redeliveredmsg.{get,set}Redelivered()dp.redelivered + + msg.propertiesmsg.getProperties()/msg.setProperty()mp.application_headers + + + msg.content_typemsg.{get,set}ContentType()mp.content_type + + + +
+ +
+ 0-10 Message Property Keys + + The QPID Messaging API also recognises special message property keys and + automatically provides a mapping to their corresponding AMQP 0-10 definitions. + + + + + When sending a message, if the properties contain an entry for + x-amqp-0-10.app-id, its value will be used to set the + message-properties.app-id property in the outgoing + message. Likewise, if an incoming message has + message-properties.app-id set, its value can be accessed + via the x-amqp-0-10.app-id message property key. + + + + + When sending a message, if the properties contain an entry for + x-amqp-0-10.content-encoding, its value will be used to + set the message-properties.content-encoding property in + the outgoing message. Likewise, if an incoming message has + message-properties.content-encoding set, its value can be + accessed via the x-amqp-0-10.content-encoding message + property key. + + + + + The routing key (delivery-properties.routing-key) in an + incoming messages can be accessed via the + x-amqp-0-10.routing-key message property. + + + + + If the timestamp delivery property is set in an incoming message + (delivery-properties.timestamp), the timestamp value will + be made available via the x-amqp-0-10.timestamp message + property. + + + This special property is currently not supported by the Qpid JMS client. + + + + + + + Accessing the AMQP 0-10 Message Timestamp in Python + + The following code fragment checks for and extracts the message timestamp from + a received message. + + + try: + msg = receiver.fetch(timeout=1) + if "x-amqp-0-10.timestamp" in msg.properties: + print("Timestamp=%s" % str(msg.properties["x-amqp-0-10.timestamp"])) + except Empty: + pass + + + + Accessing the AMQP 0-10 Message Timestamp in C++ + + The same example, except in C++. + + + messaging::Message msg; + if (receiver.fetch(msg, messaging::Duration::SECOND*1)) { + if (msg.getProperties().find("x-amqp-0-10.timestamp") != msg.getProperties().end()) { + + } + } + + +
+
+ + + + + + + + Using the Qpid JMS client +
+ A Simple Messaging Program in Java JMS + + The following program shows how to send and receive a + message using the Qpid JMS client. JMS programs typically use + JNDI to obtain connection factory and destination objects which + the application needs. In this way the configuration is kept + separate from the application code itself. + + In this example, we create a JNDI context using a + properties file, use the context to lookup a connection factory, + create and start a connection, create a session, and lookup a + destination from the JNDI context. Then we create a producer and + a consumer, send a message with the producer and receive it with + the consumer. This code should be straightforward for anyone + familiar with Java JMS. + + + "Hello world!" in Java + + package org.apache.qpid.example.jmsexample.hello; + + import javax.jms.*; + import javax.naming.Context; + import javax.naming.InitialContext; + import java.util.Properties; + + public class Hello { + + public Hello() { + } + + public static void main(String[] args) { + Hello producer = new Hello(); + producer.runTest(); + } + + private void runTest() { + try { + Properties properties = new Properties(); + properties.load(this.getClass().getResourceAsStream("hello.properties")); + Context context = new InitialContext(properties); + + ConnectionFactory connectionFactory + = (ConnectionFactory) context.lookup("qpidConnectionfactory"); + Connection connection = connectionFactory.createConnection(); + connection.start(); + + Session session=connection.createSession(false,Session.AUTO_ACKNOWLEDGE); + Destination destination = (Destination) context.lookup("topicExchange"); + + MessageProducer messageProducer = session.createProducer(destination); + MessageConsumer messageConsumer = session.createConsumer(destination); + + TextMessage message = session.createTextMessage("Hello world!"); + messageProducer.send(message); + + message = (TextMessage)messageConsumer.receive(); + System.out.println(message.getText()); + + connection.close(); + context.close(); + } + catch (Exception exp) { + exp.printStackTrace(); + } + } + } + + + + + + Loads the JNDI properties file, which specifies connection properties, queues, topics, and addressing options. See for details. + + + Creates the JNDI initial context. + + + Creates a JMS connection factory for Qpid. + + + Creates a JMS connection. + + + Activates the connection. + + + Creates a session. This session is not transactional (transactions='false'), and messages are automatically acknowledged. + + + Creates a destination for the topic exchange, so senders and receivers can use it. + + + Creates a producer that sends messages to the topic exchange. + + + Creates a consumer that reads messages from the topic exchange. + + + Reads the next available message. + + + Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. + + + Closes the JNDI context. + + + + The contents of the hello.properties file are shown below. + + + JNDI Properties File for "Hello world!" example + + java.naming.factory.initial + = org.apache.qpid.jndi.PropertiesFileInitialContextFactory + + # connectionfactory.[jndiname] = [ConnectionURL] + connectionfactory.qpidConnectionfactory + = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672' + # destination.[jndiname] = [address_string] + destination.topicExchange = amq.topic + + + + + + Defines a connection factory from which connections + can be created. The syntax of a ConnectionURL is given in + . + + + Defines a destination for which MessageProducers + and/or MessageConsumers can be created to send and receive + messages. The value for the destination in the properties + file is an address string as described in + . In the JMS + implementation MessageProducers are analogous to senders in + the Qpid Message API, and MessageConsumers are analogous to + receivers. + + + +
+ +
+ Apache Qpid JNDI Properties for AMQP Messaging + + + + Apache Qpid defines JNDI properties that can be used to specify JMS Connections and Destinations. Here is a typical JNDI properties file: + + + + JNDI Properties File + + + + The following sections describe the JNDI properties that Qpid uses. + + +
+ JNDI Properties for Apache Qpid + + Apache Qpid supports the properties shown in the following table: + + + JNDI Properties supported by Apache Qpid + + + + + Property + + + Purpose + + + + + + + connectionfactory.<jndiname> + + + + The Connection URL that the connection factory uses to perform connections. + + + + + + queue.<jndiname> + + + + A JMS queue, which is implemented as an amq.direct exchange in Apache Qpid. + + + + + + topic.<jndiname> + + + + A JMS topic, which is implemented as an amq.topic exchange in Apache Qpid. + + + + + + destination.<jndiname> + + + + Can be used for defining all amq destinations, + queues, topics and header matching, using an + address string. + + Binding URLs, which were used in + earlier versions of the Qpid Java JMS client, can + still be used instead of address + strings. + + + + + +
+
+ +
+ Connection URLs + + In JNDI properties, a Connection URL specifies properties for a connection. The format for a Connection URL is: + + + amqp://[<user>:<pass>@][<clientid>]<virtualhost>[?<option>='<value>'[&<option>='<value>']] + + + For instance, the following Connection URL specifies a user name, a password, a client ID, a virtual host ("test"), a broker list with a single broker, and a TCP host with the host name localhost using port 5672: + + + amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672' + + + Apache Qpid supports the following properties in Connection URLs: + + + Connection URL Properties + + + + + Option + + + Type + + + Description + + + + + + + brokerlist + + + see below + + + List of one or more broker addresses. + + + + + maxprefetch + + + integer + + + + The maximum number of pre-fetched messages per consumer. If not specified, default value of 500 is used. + + + Note: You can also set the default per-consumer prefetch value on a client-wide basis by configuring the client using Java system properties. + + + + + + sync_publish + + + {'persistent' | 'all'} + + + A sync command is sent after every persistent message to guarantee that it has been received; if the value is 'persistent', this is done only for persistent messages. + + + + + sync_ack + + + Boolean + + + A sync command is sent after every acknowledgement to guarantee that it has been received. + + + + + use_legacy_map_msg_format + + + Boolean + + + If you are using JMS Map messages and deploying a new client with any JMS client older than 0.8 release, you must set this to true to ensure the older clients can understand the map message encoding. + + + + + failover + + + {'singlebroker' | 'roundrobin' | 'failover_exchange' | 'nofailover' | '<class>'} + + + + This option controls failover behaviour. The method singlebroker uses only the first broker in the list, + roundrobin will try each broker given in the broker list until a connection is established, + failover_exchange connects to the initial broker given in the broker URL and will receive membership updates + via the failover exchange. nofailover disables all retry and failover logic. Any other value is interpreted as a + classname which must implement the org.apache.qpid.jms.failover.FailoverMethod interface. + + + The broker list options retries and connectdelay (described below) determine the number of times a + connection to a broker will be retried and the the length of time to wait between successive connection attempts before moving on to + the next broker in the list. The failover option cyclecount controls the number of times to loop through the list of + available brokers before finally giving up. + + + Defaults to roundrobin if the brokerlist contains multiple brokers, or singlebroker otherwise. + + + + + + ssl + + + boolean + + + + If ssl='true', use SSL for all broker connections. Overrides any per-broker settings in the brokerlist (see below) entries. If not specified, the brokerlist entry for each given broker is used to determine whether SSL is used. + + + Introduced in version 0.22. + + + + + +
+ + Broker lists are specified using a URL in this format: + + + brokerlist=<transport>://<host>[:<port>](?<param>='<value>')(&<param>='<value>')* + + For instance, this is a typical broker list: + + + brokerlist='tcp://localhost:5672' + + + + A broker list can contain more than one broker address; if so, the connection is made to the first broker in the list that is available. In general, it is better to use the failover exchange when using multiple brokers, since it allows applications to fail over if a broker goes down. + + + + Broker Lists + A broker list can specify properties to be used when connecting to the broker, such as security options. This broker list specifies options for a Kerberos connection using GSSAPI: + + + This broker list specifies SSL options: + + + + + This broker list specifies two brokers using the connectdelay and retries broker options. It also illustrates the failover connection URL + property. + + + + + + The following broker list options are supported. + + + Broker List Options + + + + + Option + + + Type + + + Description + + + + + + + heartbeat + + + integer + + + frequency of heartbeat messages (in seconds) + + + + + sasl_mechs + + + -- + + + For secure applications, we suggest CRAM-MD5, + DIGEST-MD5, or GSSAPI. The ANONYMOUS method is not + secure. The PLAIN method is secure only when used + together with SSL. For Kerberos, sasl_mechs must be + set to GSSAPI, sasl_protocol must be set to the + principal for the qpidd broker, e.g. qpidd/, and + sasl_server must be set to the host for the SASL + server, e.g. sasl.com. SASL External is supported + using SSL certification, e.g. + ssl='true'&sasl_mechs='EXTERNAL' + + + + + sasl_encryption + + + Boolean + + + If sasl_encryption='true', the JMS client attempts to negotiate a security layer with the broker using GSSAPI to encrypt the connection. Note that for this to happen, GSSAPI must be selected as the sasl_mech. + + + + + sasl_protocol + + + -- + + + Used only for + Kerberos. sasl_protocol must be + set to the principal for the qpidd broker, + e.g. qpidd/ + + + + + sasl_server + + + -- + + + For Kerberos, sasl_mechs must be set to GSSAPI, + sasl_server must be set to the host for the SASL + server, e.g. sasl.com. + + + + + trust_store + + + -- + + + path to trust store + + + + + trust_store_password + + + -- + + + Trust store password + + + + + key_store + + + -- + + + path to key store + + + + + key_store_password + + + -- + + + key store password + + + + + ssl + + + Boolean + + + If ssl='true', the JMS client will encrypt the connection to this broker using SSL. + + This can also be set/overridden for all brokers using the Connection URL options. + + + + + ssl_verify_hostname + + + Boolean + + + When using SSL you can enable hostname verification + by using ssl_verify_hostname='true' in the broker + URL. + + + + + ssl_cert_alias + + + -- + + + If multiple certificates are present in the keystore, the alias will be used to extract the correct certificate. + + + + + retries + + + integer + + + The number of times to retry connection to each broker in the broker list. Defaults to 1. + + + + + connectdelay + + + integer + + + Length of time (in milliseconds) to wait before attempting to reconnect. Defaults to 0. + + + + + connecttimeout + + + integer + + + Length of time (in milliseconds) to wait for the socket connection to succeed. A value of 0 represents an infinite timeout, i.e. the connection attempt will block until established or an error occurs. Defaults to 30000. + + + + + tcp_nodelay + + + Boolean + + + If tcp_nodelay='true', TCP packet + batching is disabled. Defaults to true since Qpid 0.14. + + + + +
+
+
+ +
+ Java JMS Message Properties + + The following table shows how Qpid Messaging API message + properties are mapped to AMQP 0-10 message properties and + delivery properties. In this table msg + refers to the Message class defined in the Qpid Messaging API, + mp refers to an AMQP 0-10 + message-properties struct, and + dp refers to an AMQP 0-10 + delivery-properties struct. + + + Java JMS Mapping to AMQP 0-10 Message Properties + + + + Java JMS Message Property + AMQP 0-10 PropertyIn these entries, mp refers to an AMQP message property, and dp refers to an AMQP delivery property. + + + + + + JMSMessageIDmp.message_id + + + qpid.subjectThis is a custom JMS property, set automatically by the Java JMS client implementation.mp.application_headers["qpid.subject"] + + + JMSXUserIDmp.user_id + + + JMSReplyTomp.reply_toThe reply_to is converted from the protocol representation into an address. + + + JMSCorrelationIDmp.correlation_id + + + JMSDeliveryModedp.delivery_mode + + + JMSPrioritydp.priority + + + JMSExpirationdp.ttlJMSExpiration = dp.ttl + currentTime + + + JMSRedelivereddp.redelivered + + + JMS Propertiesmp.application_headers + + + JMSTypemp.content_type + + + +
+ +
+ +
+ JMS MapMessage Types + + Qpid supports the Java JMS MapMessage interface, which provides support for maps in messages. The following code shows how to send a MapMessage in Java JMS. + + + Sending a Java JMS MapMessage + colors = new ArrayList(); + colors.add("red"); + colors.add("green"); + colors.add("white"); + m.setObject("colours", colors); + + Map dimensions = new HashMap(); + dimensions.put("length",10.2); + dimensions.put("width",5.1); + dimensions.put("depth",2.0); + m.setObject("dimensions",dimensions); + + List> parts = new ArrayList>(); + parts.add(Arrays.asList(new Integer[] {1,2,5})); + parts.add(Arrays.asList(new Integer[] {8,2,5})); + m.setObject("parts", parts); + + Map specs = new HashMap(); + specs.put("colours", colors); + specs.put("dimensions", dimensions); + specs.put("parts", parts); + m.setObject("specs",specs); + + producer.send(m); + ]]> + + + The following table shows the datatypes that can be sent in a MapMessage, and the corresponding datatypes that will be received by clients in Python or C++. + + + Java Datatypes in Maps + + + + Java Datatype + → Python + → C++ + + + + booleanboolbool + shortint | longint16 + intint | longint32 + longint | longint64 + floatfloatfloat + doublefloatdouble + java.lang.Stringunicodestd::string + java.util.UUIDuuidqpid::types::Uuid + java.util.MapIn Qpid, maps can nest. This goes beyond the functionality required by the JMS specification.dictVariant::Map + java.util.ListlistVariant::List + + +
+ +
+ +
+ JMS Client Logging + The JMS Client logging is handled using the Simple Logging Facade for Java (SLF4J). As the name implies, slf4j is a facade that delegates to other logging systems like log4j or JDK 1.4 logging. For more information on how to configure slf4j for specific logging systems, please consult the slf4j documentation. + + When using the log4j binding, please set the log level for org.apache.qpid explicitly. Otherwise log4j will default to DEBUG which will degrade performance considerably due to excessive logging. The recommended logging level for production is WARN. + + The following example shows the logging properties used to configure client logging for slf4j using the log4j binding. These properties can be placed in a log4j.properties file and placed in the CLASSPATH, or they can be set explicitly using the -Dlog4j.configuration property. + + + log4j Logging Properties + + + + +
+ +
+ Configuring the JMS Client + + The Qpid JMS Client allows several configuration options to customize it's behaviour at different levels of granualarity. + + + + + JVM level using JVM arguments : Configuration that affects all connections, sessions, consumers and producers created within that JVM. + + Ex. -Dmax_prefetch=1000 property specifies the message credits to use. + + + + + Connection level using Connection/Broker properties : Affects the respective connection and sessions, consumers and produces created by that connection. + + Ex. amqp://guest:guest@test/test?max_prefetch='1000' + &brokerlist='tcp://localhost:5672' + property specifies the message credits to use. This overrides any value specified via the JVM argument max_prefetch. + Please refer to the section for a complete list of all properties and how to use them. + + + + + Destination level using Addressing options : Affects the producer(s) and consumer(s) created using the respective destination. + + Ex. my-queue; {create: always, link:{capacity: 10}}, where capacity option specifies the message credits to use. This overrides any connection level configuration. + Please refer to the section for a complete understanding of addressing and it's various options. + + + + Some of these config options are available at all three levels (Ex. max_prefetch), while others are available only at JVM or connection level. + +
+ Qpid JVM Arguments + + + Config Options For Connection Behaviour + + + + Property Name + Type + Default Value + Description + + + + + qpid.amqp.version + string + 0-10 + Sets the AMQP version to be used - currently supports one of {0-8,0-9,0-91,0-10}.The client will begin negotiation at the specified version and only negotiate downwards if the Broker does not support the specified version. + + + qpid.heartbeat + int + 120 (secs) + The heartbeat interval in seconds. Two consective misssed heartbeats will result in the connection timing out.This can also be set per connection using the Connection URL options. + + + + ignore_setclientID + boolean + false + If a client ID is specified in the connection URL it's used or else an ID is generated. If an ID is specified after it's been set Qpid will throw an exception. Setting this property to 'true' will disable that check and allow you to set a client ID of your choice later on. + + + +
+ + + + Config Options For Session Behaviour + + + + Property Name + Type + Default Value + Description + + + + + qpid.session.command_limit + int + 65536 + Limits the # of unacked commands + + + + qpid.session.byte_limit + int + 1048576 + Limits the # of unacked commands in terms of bytes + + + + qpid.use_legacy_map_message + boolean + false + If set will use the old map message encoding. By default the Map messages are encoded using the 0-10 map encoding.This can also be set per connection using the Connection URL options. + + + + qpid.jms.daemon.dispatcher + boolean + false + Controls whether the Session dispatcher thread is a daemon thread or not. If this system property is set to true then the Session dispatcher threads will be created as daemon threads. This setting is introduced in version 0.16. + + + +
+ + + Config Options For Consumer Behaviour + + + + Property Name + Type + Default Value + Description + + + + + max_prefetch + int + 500 + Maximum number of pre-fetched messages per consumer. This can also be defaulted for consumers created on a particular connection using the Connection URL options, or per destination (see the capacity option under link properties in addressing) + + + + qpid.session.max_ack_delay + long + 1000 (ms) + Timer interval to flush message acks in buffer when using AUTO_ACK and DUPS_OK. When using the above ack modes, message acks are batched and sent if one of the following conditions are met (which ever happens first). + + When the ack timer fires. + if un_acked_msg_count > max_prefetch/2. + + + The ack timer can be disabled by setting it to 0. + + + + + sync_ack + boolean + false + If set, each message will be acknowledged synchronously. When using AUTO_ACK mode, you need to set this to "true", in order to get the correct behaviour as described by the JMS spec.This is set to false by default for performance reasons, therefore by default AUTO_ACK behaves similar to DUPS_OK.This can also be set per connection using the Connection URL options. + + + +
+ + + Config Options For Producer Behaviour + + + + Property Name + Type + Default Value + Description + + + + + sync_publish + string + "" (disabled) + If one of {persistent|all} is set then persistent messages or all messages will be sent synchronously.This can also be set per connection using the Connection URL options. + + + +
+ + + Config Options For Threading + + + + Property Name + Type + Default Value + Description + + + + + qpid.thread_factory + string + org.apache.qpid.thread.DefaultThreadFactory + Specifies the thread factory to use.If using a real time JVM, you need to set the above property to org.apache.qpid.thread.RealtimeThreadFactory. + + + + qpid.rt_thread_priority + int + 20 + Specifies the priority (1-99) for Real time threads created by the real time thread factory. + + + +
+ + + Config Options For I/O + + + + Property Name + Type + Default Value + Description + + + + + qpid.transport + string + org.apache.qpid.transport.network.io.IoNetworkTransport + The transport implementation to be used.A user could specify an alternative transport mechanism that implements the interface org.apache.qpid.transport.network.OutgoingNetworkTransport. + + + qpid.sync_op_timeout + long + 60000 + The length of time (in milliseconds) to wait for a synchronous operation to complete.For compatibility with older clients, the synonym amqj.default_syncwrite_timeout is supported. + + + qpid.tcp_nodelay + boolean + true + + Sets the TCP_NODELAY property of the underlying socket. The default was changed to true as of Qpid 0.14. + This can also be set per connection using the Connection URL options. + For compatibility with older clients, the synonym amqj.tcp_nodelay is supported. + + + + qpid.send_buffer_size + integer + 65535 + + Sets the SO_SNDBUF property of the underlying socket. Added in Qpid 0.16. + For compatibility with older clients, the synonym amqj.sendBufferSize is supported. + + + + qpid.receive_buffer_size + integer + 65535 + + Sets the SO_RCVBUF property of the underlying socket. Added in Qpid 0.16. + For compatibility with older clients, the synonym amqj.receiveBufferSize is supported. + + + + qpid.failover_method_timeout + long + 60000 + + During failover, this is the timeout for each attempt to try to re-establish the connection. + If a reconnection attempt exceeds the timeout, the entire failover process is aborted. + It is only applicable for AMQP 0-8/0-9/0-9-1 clients. + + + + +
+ + + Config Options For Security + + + + Property Name + Type + Default Value + Description + + + + + qpid.sasl_mechs + string + PLAIN + The SASL mechanism to be used. More than one could be specified as a comma separated list.We currently support the following mechanisms {PLAIN | GSSAPI | EXTERNAL}.This can also be set per connection using the Connection URL options. + + + + qpid.sasl_protocol + string + AMQP + When using GSSAPI as the SASL mechanism, sasl_protocol must be set to the principal for the qpidd broker, e.g. qpidd.This can also be set per connection using the Connection URL options. + + + + qpid.sasl_server_name + string + localhost + When using GSSAPI as the SASL mechanism, sasl_server must be set to the host for the SASL server, e.g. example.com.This can also be set per connection using the Connection URL options. + + + +
+ + + Config Options For Security - Standard JVM properties needed when using GSSAPI as the SASL mechanism.<footnote><para>Please refer to the Java security documentation for a complete understanding of the above properties.</para></footnote> + + + + Property Name + Type + Default Value + Description + + + + + javax.security.auth.useSubjectCredsOnly + boolean + true + If set to 'false', forces the SASL GASSPI client to obtain the kerberos credentials explicitly instead of obtaining from the "subject" that owns the current thread. + + + + java.security.auth.login.config + string + + Specifies the jass configuration file.Ex-Djava.security.auth.login.config=myjas.conf + Here is the sample myjas.conf JASS configuration file: + + + +
+ + + Config Options For Security - Using SSL for securing connections or using EXTERNAL as the SASL mechanism. + + + + Property Name + Type + Default Value + Description + + + + + qpid.ssl_timeout + long + 60000 + Timeout value used by the Java SSL engine when waiting on operations. + + + + qpid.ssl.KeyManagerFactory.algorithm + string + - + + The key manager factory algorithm name. If not set, defaults to the value returned from the Java runtime call KeyManagerFactory.getDefaultAlgorithm() + For compatibility with older clients, the synonym qpid.ssl.keyStoreCertType is supported. + + + + + qpid.ssl.TrustManagerFactory.algorithm + string + - + + The trust manager factory algorithm name. If not set, defaults to the value returned from the Java runtime call TrustManagerFactory.getDefaultAlgorithm() + For compatibility with older clients, the synonym qpid.ssl.trustStoreCertType is supported. + + + + +
+ + + Config Options For Security - Standard JVM properties needed when Using SSL for securing connections or using EXTERNAL as the SASL mechanism.<footnote><para>Qpid allows you to have per connection key and trust stores if required. If specified per connection, the JVM arguments are ignored.</para></footnote> + + + + Property Name + Type + Default Value + Description + + + + + javax.net.ssl.keyStore + string + jvm default + Specifies the key store path.This can also be set per connection using the Connection URL options. + + + + javax.net.ssl.keyStorePassword + string + jvm default + Specifies the key store password.This can also be set per connection using the Connection URL options. + + + + javax.net.ssl.trustStore + string + jvm default + Specifies the trust store path.This can also be set per connection using the Connection URL options. + + + + javax.net.ssl.trustStorePassword + string + jvm default + Specifies the trust store password.This can also be set per connection using the Connection URL options. + + + +
+
+
+ + + + + Using the Qpid WCF client +
+ XML and Binary Bindings + + The Qpid WCF client provides two bindings, each with support for + Windows .NET transactions. + + The AmqpBinding is suitable for communication between two WCF + applications. By default it uses the WCF binary .NET XML encoder + (BinaryMessageEncodingBindingElement) for efficient message + transmission, but it can also use the text and Message Transmission + Optimization Mechanism (MTOM) encoders. Here is a traditional service + model sample program using the AmqpBinding. It assumes that the queue + "hello_service_node" has been created and configured on the AMQP + broker. + + + Traditional service model "Hello world!" example + + + channelFactory = + new ChannelFactory(amqpBinding, clientEndpoint); + IHelloService clientProxy = channelFactory.CreateChannel(); + + clientProxy.SayHello("Greetings from WCF client"); + + // wait for service to process the greeting + while (HelloService.GreetingCount == 0) + { + Thread.Sleep(100); + } + channelFactory.Close(); + serviceHost.Close(); + } + catch (Exception e) + { + Console.WriteLine("Exception: {0}", e); + } + } + } + } + ]]> + + + The second binding, AmqpBinaryBinding, is suitable for WCF + applications that need to inter-operate with non-WCF clients or that + wish to have direct access to the raw wire representation of the + message body. It relies on a custom encoder to read and write raw + (binary) content which operates similarly to the ByteStream encoder + (introduced in .NET 4.0). The encoder presents an abstract XML + infoset view of the raw message content on input. On output, the + encoder does the reverse and peels away the XML infoset layer exposing + the raw content to the wire representation of the message body. The + application must do the inverse of what the encoder does to allow the + XML infoset wrapper to cancel properly. This is demonstrated in the + following sample code (using the channel programming model) which + directly manipulates or provides callbacks to the WCF message readers + and writers when the content is consumed. In contrast to the + AmqpBinding sample where the simple greeting is encapsulated in a + compressed SOAP envelope, the wire representation of the message + contains the raw content and is identical and fully interoperable with + the Qpid C++ "Hello world!" example. + + + Binary "Hello world!" example using the channel model + 0) + { + broker = args[0]; + } + + if (args.Length > 1) + { + port = int.Parse(args[1]); + } + + if (args.Length > 2) + { + target = args[2]; + } + + if (args.Length > 3) + { + source = args[3]; + } + + AmqpBinaryBinding binding = new AmqpBinaryBinding(); + binding.BrokerHost = broker; + binding.BrokerPort = port; + + IChannelFactory receiverFactory = binding.BuildChannelFactory(); + receiverFactory.Open(); + IInputChannel receiver = receiverFactory.CreateChannel(new EndpointAddress("amqp:" + source)); + receiver.Open(); + + IChannelFactory senderFactory = binding.BuildChannelFactory(); + senderFactory.Open(); + IOutputChannel sender = senderFactory.CreateChannel(new EndpointAddress("amqp:" + target)); + sender.Open(); + + sender.Send(Message.CreateMessage(MessageVersion.None, "", new HelloWorldBinaryBodyWriter())); + + Message message = receiver.Receive(); + XmlDictionaryReader reader = message.GetReaderAtBodyContents(); + while (!reader.HasValue) + { + reader.Read(); + } + + byte[] binaryContent = reader.ReadContentAsBase64(); + string text = Encoding.UTF8.GetString(binaryContent); + + Console.WriteLine(text); + + senderFactory.Close(); + receiverFactory.Close(); + } + } + + public class HelloWorldBinaryBodyWriter : BodyWriter + { + public HelloWorldBinaryBodyWriter() : base (true) {} + + protected override void OnWriteBodyContents(XmlDictionaryWriter writer) + { + byte[] binaryContent = Encoding.UTF8.GetBytes("Hello world!"); + + // wrap the content: + writer.WriteStartElement("Binary"); + writer.WriteBase64(binaryContent, 0, binaryContent.Length); + } + } + } + ]]> + + + Bindings define ChannelFactories and ChannelListeners associated with + an AMQP Broker. WCF will frequently automatically create and manage + the life cycle of a these and the resulting IChannel objects used in + message transfer. The binding parameters that can be set are: + + + WCF Binding Parameters + + + + + + + Parameter + Default + Description + + + + + + BrokerHost + + + localhost + + + The broker's server name. Currently the WCF channel + only supports connections with a single broker. + Failover to multiple brokers will be provided in the + future. + + + + + + BrokerPort + + + 5672 + + + The port the broker is listening on. + + + + + + PrefetchLimit + + + 0 + + + The number of messages to prefetch from the amqp + broker before the application actually consumes them. + Increasing this number can dramatically increase the + read performance in some circumstances. + + + + + + Shared + + + false + + + Indicates if separate channels to the same broker can + share an underlying AMQP tcp connection (provided they + also share the same authentication credentials). + + + + + + TransferMode + + + buffered + + + Indicates whether the channel's encoder uses the WCF + BufferManager cache to temporarily store message + content during the encoding/decoding phase. For small + to medium sized SOAP based messages, buffered is + usually the preferred choice. For binary messages, + streamed TransferMode is the more efficient mode. + + + + +
+
+ +
+ Endpoints + + In Qpid 0.6 the WCF Endpoints map to simple AMQP 0-10 + exchanges (IOutputChannel) or AMQP 0-10 queues (IInputChannel). + The format for an IOutputChannel is + + + + and for an IInputChannel is + + + + The routing key is in fact a default value associated with + the particular channel. Outgoing messages can always have their + routing key uniquely set. + + If the respective queue or exchange doesn't exist, an exception + is thrown when opening the channel. Queues and exchanges can be + created and configured using qpid-config. + +
+ +
+ Message Headers + + AMQP specific message headers can be set on or retrieved + from the ServiceModel.Channels.Message using the AmqpProperties + type. + + For example, on output: + + + + On input the headers can be accessed from the Message or extracted + from the operation context + + + +
+ +
+ Security + + To engage TLS/SSL: + + + + Currently the WCF client only provides SASL PLAIN (i.e. username and + password) authentication. To provide a username and password, you can + set the DefaultAmqpCredential value in the binding. This value can be + overridden or set for a binding's channel factories and listeners, + either by setting the ClientCredentials as a binding parameter, or by + using an AmqpCredential as a binding parameter. The search order for + credentials is the AmqpCredential binding parameter, followed by the + ClientCredentials (unless IgnoreEndpointClientCredentials has been + set), and finally defaulting to the DefaultAmqpCredential of the + binding itself. Here is a sample using ClientCredentials: + + (bindingParameters); +]]> + +
+ +
+ Transactions + + The WCF channel provides a transaction resource manager + module and a recovery module that together provide distributed + transaction support with one-phase optimization. Some + configuration is required on Windows machines to enable + transaction support (see your installation notes or top level + ReadMe.txt file for instructions). Once properly configured, + the Qpid WCF channel acts as any other System.Transactions aware + resource, capable of participating in explicit or implicit + transactions. + + Server code: + + + + Because this operation involves two transaction resources, the + database and the AMQP message broker, this operates as a full two + phase commit transaction managed by the Distributed Transaction + Coordinator service. If the transaction proceeds without error, + both ExactlyOnceReceived is incremented in the database and the AMQP + message is consumed from the broker. Otherwise, ExactlyOnceReceived is + unchanged and AMQP message is returned to its queue on the broker. + + For the client code a few changes are made to the non-transacted + example. For "exactly once" semantics, we set the AMQP "Durable" + message property and enclose the transacted activities in a + TransactionScope: + + channelFactory = +new ChannelFactory(amqpBinding, clientEndpoint); +IHelloService clientProxy = channelFactory.CreateChannel(); + +using (TransactionScope ts = new TransactionScope()) +{ + AmqpProperties amqpProperties = new AmqpProperties(); + clientProxy.SayHello("Greetings from WCF client"); + // increment ExactlyOnceSent counter on DB + ts.Complete(); +} +]]> + +
+ + + + The .NET Binding for the C++ Messaging Client + + The .NET Binding for the C++ Qpid Messaging Client is a library that gives + any .NET program access to Qpid C++ Messaging objects and methods. + +
+ .NET Binding for the C++ Messaging Client Component Architecture + + + + +This diagram illustrates the code and library components of the binding +and the hierarchical relationships between them. + + + .NET Binding for the C++ Messaging Client Component Architecture + + + + Component Name + Component Function + + + + + QPID Messaging C++ Libraries + The QPID Messaging C++ core run time system + + + Unmanaged C++ Example Source Programs + Ordinary C++ programs that illustrate using qpid/cpp Messaging directly + in a native Windows environment. + + + .NET Messaging Binding Library + The .NET Messaging Binding library provides interoprability between + managed .NET programs and the unmanaged, native Qpid Messaging C++ core + run time system. .NET programs create a Reference to this library thereby + exposing all of the native C++ Messaging functionality to programs + written in any .NET language. + + + .NET Messaging Managed Callback Library + An extension of the .NET Messaging Binding Library that provides message + callbacks in a managed .NET environment. + + + Managed C# .NET Example Source Programs + Various C# example programs that illustrate using .NET Binding for C++ Messaging in the .NET environment. + + + +
+
+ +
+ .NET Binding for the C++ Messaging Client Examples + + This chapter describes the various sample programs that + are available to illustrate common Qpid Messaging usage. + + + Example : Client - Server + + + + + + Example Name + Example Description + + + + + csharp.example.server + Creates a Receiver and listens for messages. + Upon message reception the message content is converted to upper case + and forwarded to the received message's ReplyTo address. + + + csharp.example.client + Sends a series of messages to the Server and prints the original message + content and the received message content. + + + +
+ + + Example : Map Sender – Map Receiver + + + + + + Example Name + Example Description + + + + + csharp.map.receiver + Creates a Receiver and listens for a map message. + Upon message reception the message is decoded and displayed on the console. + + + csharp.map.sender + Creates a map message and sends it to map.receiver. + The map message contains values for every supported .NET Messaging + Binding data type. + + + +
+ + + Example : Spout - Drain + + + + + + Example Name + Example Description + + + + + csharp.example.spout + Spout is a more complex example of code that generates a series of messages + and sends them to peer program Drain. Flexible command line arguments allow + the user to specify a variety of message and program options. + + + csharp.example.drain + Drain is a more complex example of code that receives a series of messages + and displays their contents on the console. + + + +
+ + + Example : Map Callback Sender – Map Callback Receiver + + + + + + Example Name + Example Description + + + + + csharp.map.callback.receiver + Creates a Receiver and listens for a map message. + Upon message reception the message is decoded and displayed on the console. + This example illustrates the use of the C# managed code callback mechanism + provided by .NET Messaging Binding Managed Callback Library. + + + csharp.map.callback.sender + Creates a map message and sends it to map_receiver. + The map message contains values for every supported .NET Messaging + Binding data type. + + + +
+ + + Example - Declare Queues + + + + + + Example Name + Example Description + + + + + csharp.example.declare_queues + A program to illustrate creating objects on a broker. + This program creates a queue used by spout and drain. + + + +
+ + + Example: Direct Sender - Direct Receiver + + + + + + Example Name + Example Description + + + + + csharp.direct.receiver + Creates a Receiver and listens for a messages. + Upon message reception the message is decoded and displayed on the console. + + + csharp.direct.sender + Creates a series of messages and sends them to csharp.direct.receiver. + + + +
+ + + Example: Hello World + + + + + + Example Name + Example Description + + + + + csharp.example.helloworld + A program to send a message and to receive the same message. + + + +
+ +
+ +
+ .NET Binding Class Mapping to Underlying C++ Messaging API + + This chapter describes the specific mappings between + classes in the .NET Binding and the underlying C++ Messaging + API. + +
+ .NET Binding for the C++ Messaging API Class: Address + + .NET Binding for the C++ Messaging API Class: Address + + + + + + .NET Binding Class: Address + + + Language + Syntax + + + + + C++ + class Address + + + .NET + public ref class Address + + + Constructor + + + C++ + Address(); + + + .NET + public Address(); + + + Constructor + + + C++ + Address(const std::string& address); + + + .NET + public Address(string address); + + + Constructor + + + C++ + Address(const std::string& name, const std::string& subject, const qpid::types::Variant::Map& options, const std::string& type = ""); + + + .NET + public Address(string name, string subject, Dictionary<string, object> options); + + + .NET + public Address(string name, string subject, Dictionary<string, object> options, string type); + + + Copy constructor + + + C++ + Address(const Address& address); + + + .NET + public Address(Address address); + + + Destructor + + + C++ + ~Address(); + + + .NET + ~Address(); + + + Finalizer + + + C++ + n/a + + + .NET + !Address(); + + + Copy assignment operator + + + C++ + Address& operator=(const Address&); + + + .NET + public Address op_Assign(Address rhs); + + + Property: Name + + + C++ + const std::string& getName() const; + + + C++ + void setName(const std::string&); + + + .NET + public string Name { get; set; } + + + Property: Subject + + + C++ + const std::string& getSubject() const; + + + C++ + void setSubject(const std::string&); + + + .NET + public string Subject { get; set; } + + + Property: Options + + + C++ + const qpid::types::Variant::Map& getOptions() const; + + + C++ + qpid::types::Variant::Map& getOptions(); + + + C++ + void setOptions(const qpid::types::Variant::Map&); + + + .NET + public Dictionary<string, object> Options { get; set; } + + + Property: Type + + + C++ + std::string getType() const; + + + C++ + void setType(const std::string&); + + + .NET + public string Type { get; set; } + + + Miscellaneous + + + C++ + std::string str() const; + + + .NET + public string ToStr(); + + + Miscellaneous + + + C++ + operator bool() const; + + + .NET + n/a + + + Miscellaneous + + + C++ + bool operator !() const; + + + .NET + n/a + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Connection + + .NET Binding for the C++ Messaging API Class: Connection + + + + + + .NET Binding Class: Connection + + + Language + Syntax + + + + + C++ + class Connection : public qpid::messaging::Handle<ConnectionImpl> + + + .NET + public ref class Connection + + + Constructor + + + C++ + Connection(ConnectionImpl* impl); + + + .NET + n/a + + + Constructor + + + C++ + Connection(); + + + .NET + n/a + + + Constructor + + + C++ + Connection(const std::string& url, const qpid::types::Variant::Map& options = qpid::types::Variant::Map()); + + + .NET + public Connection(string url); + + + .NET + public Connection(string url, Dictionary<string, object> options); + + + Constructor + + + C++ + Connection(const std::string& url, const std::string& options); + + + .NET + public Connection(string url, string options); + + + Copy Constructor + + + C++ + Connection(const Connection&); + + + .NET + public Connection(Connection connection); + + + Destructor + + + C++ + ~Connection(); + + + .NET + ~Connection(); + + + Finalizer + + + C++ + n/a + + + .NET + !Connection(); + + + Copy assignment operator + + + C++ + Connection& operator=(const Connection&); + + + .NET + public Connection op_Assign(Connection rhs); + + + Method: SetOption + + + C++ + void setOption(const std::string& name, const qpid::types::Variant& value); + + + .NET + public void SetOption(string name, object value); + + + Method: open + + + C++ + void open(); + + + .NET + public void Open(); + + + Property: isOpen + + + C++ + bool isOpen(); + + + .NET + public bool IsOpen { get; } + + + Method: close + + + C++ + void close(); + + + .NET + public void Close(); + + + Method: createTransactionalSession + + + C++ + Session createTransactionalSession(const std::string& name = std::string()); + + + .NET + public Session CreateTransactionalSession(); + + + .NET + public Session CreateTransactionalSession(string name); + + + Method: createSession + + + C++ + Session createSession(const std::string& name = std::string()); + + + .NET + public Session CreateSession(); + + + .NET + public Session CreateSession(string name); + + + Method: getSession + + + C++ + Session getSession(const std::string& name) const; + + + .NET + public Session GetSession(string name); + + + Property: AuthenticatedUsername + + + C++ + std::string getAuthenticatedUsername(); + + + .NET + public string GetAuthenticatedUsername(); + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Duration + + .NET Binding for the C++ Messaging API Class: Duration + + + + + + .NET Binding Class: Duration + + + Language + Syntax + + + + + C++ + class Duration + + + .NET + public ref class Duration + + + Constructor + + + C++ + explicit Duration(uint64_t milliseconds); + + + .NET + public Duration(ulong mS); + + + Copy constructor + + + C++ + n/a + + + .NET + public Duration(Duration rhs); + + + Destructor + + + C++ + default + + + .NET + default + + + Finalizer + + + C++ + n/a + + + .NET + default + + + Property: Milliseconds + + + C++ + uint64_t getMilliseconds() const; + + + .NET + public ulong Milliseconds { get; } + + + Operator: * + + + C++ + Duration operator*(const Duration& duration, uint64_t multiplier); + + + .NET + public static Duration operator *(Duration dur, ulong multiplier); + + + .NET + public static Duration Multiply(Duration dur, ulong multiplier); + + + C++ + Duration operator*(uint64_t multiplier, const Duration& duration); + + + .NET + public static Duration operator *(ulong multiplier, Duration dur); + + + .NET + public static Duration Multiply(ulong multiplier, Duration dur); + + + Constants + + + C++ + static const Duration FOREVER; + + + C++ + static const Duration IMMEDIATE; + + + C++ + static const Duration SECOND; + + + C++ + static const Duration MINUTE; + + + .NET + public sealed class DurationConstants + + + .NET + public static Duration FORVER; + + + .NET + public static Duration IMMEDIATE; + + + .NET + public static Duration MINUTE; + + + .NET + public static Duration SECOND; + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: FailoverUpdates + + .NET Binding for the C++ Messaging API Class: FailoverUpdates + + + + + + .NET Binding Class: FailoverUpdates + + + Language + Syntax + + + + + C++ + class FailoverUpdates + + + .NET + public ref class FailoverUpdates + + + Constructor + + + C++ + FailoverUpdates(Connection& connection); + + + .NET + public FailoverUpdates(Connection connection); + + + Destructor + + + C++ + ~FailoverUpdates(); + + + .NET + ~FailoverUpdates(); + + + Finalizer + + + C++ + n/a + + + .NET + !FailoverUpdates(); + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Message + + .NET Binding for the C++ Messaging API Class: Message + + + + + + .NET Binding Class: Message + + + Language + Syntax + + + + + C++ + class Message + + + .NET + public ref class Message + + + Constructor + + + C++ + Message(const std::string& bytes = std::string()); + + + .NET + Message(); + + + .NET + Message(System::String ^ theStr); + + + .NET + Message(System::Object ^ theValue); + + + .NET + Message(array<System::Byte> ^ bytes); + + + Constructor + + + C++ + Message(const char*, size_t); + + + .NET + public Message(byte[] bytes, int offset, int size); + + + + Copy constructor + + + C++ + Message(const Message&); + + + .NET + public Message(Message message); + + + + Copy assignment operator + + + C++ + Message& operator=(const Message&); + + + .NET + public Message op_Assign(Message rhs); + + + Destructor + + + C++ + ~Message(); + + + .NET + ~Message(); + + + Finalizer + + + C++ + n/a + + + .NET + !Message() + + + Property: ReplyTo + + + C++ + void setReplyTo(const Address&); + + + C++ + const Address& getReplyTo() const; + + + .NET + public Address ReplyTo { get; set; } + + + Property: Subject + + + C++ + void setSubject(const std::string&); + + + C++ + const std::string& getSubject() const; + + + .NET + public string Subject { get; set; } + + + Property: ContentType + + + C++ + void setContentType(const std::string&); + + + C++ + const std::string& getContentType() const; + + + .NET + public string ContentType { get; set; } + + + Property: MessageId + + + C++ + void setMessageId(const std::string&); + + + C++ + const std::string& getMessageId() const; + + + .NET + public string MessageId { get; set; } + + + Property: UserId + + + C++ + void setUserId(const std::string&); + + + C++ + const std::string& getUserId() const; + + + .NET + public string UserId { get; set; } + + + Property: CorrelationId + + + C++ + void setCorrelationId(const std::string&); + + + C++ + const std::string& getCorrelationId() const; + + + .NET + public string CorrelationId { get; set; } + + + Property: Priority + + + C++ + void setPriority(uint8_t); + + + C++ + uint8_t getPriority() const; + + + .NET + public byte Priority { get; set; } + + + Property: Ttl + + + C++ + void setTtl(Duration ttl); + + + C++ + Duration getTtl() const; + + + .NET + public Duration Ttl { get; set; } + + + Property: Durable + + + C++ + void setDurable(bool durable); + + + C++ + bool getDurable() const; + + + .NET + public bool Durable { get; set; } + + + Property: Redelivered + + + C++ + bool getRedelivered() const; + + + C++ + void setRedelivered(bool); + + + .NET + public bool Redelivered { get; set; } + + + Method: SetProperty + + + C++ + void setProperty(const std::string&, const qpid::types::Variant&); + + + .NET + public void SetProperty(string name, object value); + + + Property: Properties + + + C++ + const qpid::types::Variant::Map& getProperties() const; + + + C++ + qpid::types::Variant::Map& getProperties(); + + + .NET + public Dictionary<string, object> Properties { get; set; } + + + Method: SetContent + + + C++ + void setContent(const std::string&); + + + C++ + void setContent(const char* chars, size_t count); + + + .NET + public void SetContent(byte[] bytes); + + + .NET + public void SetContent(string content); + + + .NET + public void SetContent(byte[] bytes, int offset, int size); + + + Method: GetContent + + + C++ + std::string getContent() const; + + + .NET + public string GetContent(); + + + .NET + public void GetContent(byte[] arr); + + + .NET + public void GetContent(Collection<object> __p1); + + + .NET + public void GetContent(Dictionary<string, object> dict); + + + Method: GetContentPtr + + + C++ + const char* getContentPtr() const; + + + .NET + n/a + + + Property: ContentSize + + + C++ + size_t getContentSize() const; + + + .NET + public ulong ContentSize { get; } + + + Struct: EncodingException + + + C++ + struct EncodingException : qpid::types::Exception + + + .NET + n/a + + + Method: decode + + + C++ + void decode(const Message& message, qpid::types::Variant::Map& map, const std::string& encoding = std::string()); + + + C++ + void decode(const Message& message, qpid::types::Variant::List& list, const std::string& encoding = std::string()); + + + .NET + n/a + + + Method: encode + + + C++ + void encode(const qpid::types::Variant::Map& map, Message& message, const std::string& encoding = std::string()); + + + C++ + void encode(const qpid::types::Variant::List& list, Message& message, const std::string& encoding = std::string()); + + + .NET + n/a + + + Method: AsString + + + C++ + n/a + + + .NET + public string AsString(object obj); + + + .NET + public string ListAsString(Collection<object> list); + + + .NET + public string MapAsString(Dictionary<string, object> dict); + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Receiver + + .NET Binding for the C++ Messaging API Class: Receiver + + + + + + .NET Binding Class: Receiver + + + Language + Syntax + + + + + C++ + class Receiver + + + .NET + public ref class Receiver + + + Constructor + + + .NET + Constructed object is returned by Session.CreateReceiver + + + Copy constructor + + + C++ + Receiver(const Receiver&); + + + .NET + public Receiver(Receiver receiver); + + + Destructor + + + C++ + ~Receiver(); + + + .NET + ~Receiver(); + + + Finalizer + + + C++ + n/a + + + .NET + !Receiver() + + + Copy assignment operator + + + C++ + Receiver& operator=(const Receiver&); + + + .NET + public Receiver op_Assign(Receiver rhs); + + + Method: Get + + + C++ + bool get(Message& message, Duration timeout=Duration::FOREVER); + + + .NET + public bool Get(Message mmsgp); + + + .NET + public bool Get(Message mmsgp, Duration durationp); + + + Method: Get + + + C++ + Message get(Duration timeout=Duration::FOREVER); + + + .NET + public Message Get(); + + + .NET + public Message Get(Duration durationp); + + + Method: Fetch + + + C++ + bool fetch(Message& message, Duration timeout=Duration::FOREVER); + + + .NET + public bool Fetch(Message mmsgp); + + + .NET + public bool Fetch(Message mmsgp, Duration duration); + + + Method: Fetch + + + C++ + Message fetch(Duration timeout=Duration::FOREVER); + + + .NET + public Message Fetch(); + + + .NET + public Message Fetch(Duration durationp); + + + Property: Capacity + + + C++ + void setCapacity(uint32_t); + + + C++ + uint32_t getCapacity(); + + + .NET + public uint Capacity { get; set; } + + + Property: Available + + + C++ + uint32_t getAvailable(); + + + .NET + public uint Available { get; } + + + Property: Unsettled + + + C++ + uint32_t getUnsettled(); + + + .NET + public uint Unsettled { get; } + + + Method: Close + + + C++ + void close(); + + + .NET + public void Close(); + + + Property: IsClosed + + + C++ + bool isClosed() const; + + + .NET + public bool IsClosed { get; } + + + Property: Name + + + C++ + const std::string& getName() const; + + + .NET + public string Name { get; } + + + Property: Session + + + C++ + Session getSession() const; + + + .NET + public Session Session { get; } + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Sender + + .NET Binding for the C++ Messaging API Class: Sender + + + + + + .NET Binding Class: Sender + + + Language + Syntax + + + + + C++ + class Sender + + + .NET + public ref class Sender + + + Constructor + + + .NET + Constructed object is returned by Session.CreateSender + + + Copy constructor + + + C++ + Sender(const Sender&); + + + .NET + public Sender(Sender sender); + + + Destructor + + + C++ + ~Sender(); + + + .NET + ~Sender(); + + + Finalizer + + + C++ + n/a + + + .NET + !Sender() + + + Copy assignment operator + + + C++ + Sender& operator=(const Sender&); + + + .NET + public Sender op_Assign(Sender rhs); + + + Method: Send + + + C++ + void send(const Message& message, bool sync=false); + + + .NET + public void Send(Message mmsgp); + + + .NET + public void Send(Message mmsgp, bool sync); + + + Method: Close + + + C++ + void close(); + + + .NET + public void Close(); + + + Property: Capacity + + + C++ + void setCapacity(uint32_t); + + + C++ + uint32_t getCapacity(); + + + .NET + public uint Capacity { get; set; } + + + Property: Available + + + C++ + uint32_t getAvailable(); + + + .NET + public uint Available { get; } + + + Property: Unsettled + + + C++ + uint32_t getUnsettled(); + + + .NET + public uint Unsettled { get; } + + + Property: Name + + + C++ + const std::string& getName() const; + + + .NET + public string Name { get; } + + + Property: Session + + + C++ + Session getSession() const; + + + .NET + public Session Session { get; } + + + +
+
+
+ .NET Binding for the C++ Messaging API Class: Session + + .NET Binding for the C++ Messaging API Class: Session + + + + + + .NET Binding Class: Session + + + Language + Syntax + + + + + C++ + class Session + + + .NET + public ref class Session + + + Constructor + + + .NET + Constructed object is returned by Connection.CreateSession + + + Copy constructor + + + C++ + Session(const Session&); + + + .NET + public Session(Session session); + + + Destructor + + + C++ + ~Session(); + + + .NET + ~Session(); + + + Finalizer + + + C++ + n/a + + + .NET + !Session() + + + Copy assignment operator + + + C++ + Session& operator=(const Session&); + + + .NET + public Session op_Assign(Session rhs); + + + Method: Close + + + C++ + void close(); + + + .NET + public void Close(); + + + Method: Commit + + + C++ + void commit(); + + + .NET + public void Commit(); + + + Method: Rollback + + + C++ + void rollback(); + + + .NET + public void Rollback(); + + + Method: Acknowledge + + + C++ + void acknowledge(bool sync=false); + + + C++ + void acknowledge(Message&, bool sync=false); + + + .NET + public void Acknowledge(); + + + .NET + public void Acknowledge(bool sync); + + + .NET + public void Acknowledge(Message __p1); + + + .NET + public void Acknowledge(Message __p1, bool __p2); + + + Method: Reject + + + C++ + void reject(Message&); + + + .NET + public void Reject(Message __p1); + + + Method: Release + + + C++ + void release(Message&); + + + .NET + public void Release(Message __p1); + + + Method: Sync + + + C++ + void sync(bool block=true); + + + .NET + public void Sync(); + + + .NET + public void Sync(bool block); + + + Property: Receivable + + + C++ + uint32_t getReceivable(); + + + .NET + public uint Receivable { get; } + + + Property: UnsettledAcks + + + C++ + uint32_t getUnsettledAcks(); + + + .NET + public uint UnsetledAcks { get; } + + + Method: NextReceiver + + + C++ + bool nextReceiver(Receiver&, Duration timeout=Duration::FOREVER); + + + .NET + public bool NextReceiver(Receiver rcvr); + + + .NET + public bool NextReceiver(Receiver rcvr, Duration timeout); + + + Method: NextReceiver + + + C++ + Receiver nextReceiver(Duration timeout=Duration::FOREVER); + + + .NET + public Receiver NextReceiver(); + + + .NET + public Receiver NextReceiver(Duration timeout); + + + Method: CreateSender + + + C++ + Sender createSender(const Address& address); + + + .NET + public Sender CreateSender(Address address); + + + Method: CreateSender + + + C++ + Sender createSender(const std::string& address); + + + .NET + public Sender CreateSender(string address); + + + Method: CreateReceiver + + + C++ + Receiver createReceiver(const Address& address); + + + .NET + public Receiver CreateReceiver(Address address); + + + Method: CreateReceiver + + + C++ + Receiver createReceiver(const std::string& address); + + + .NET + public Receiver CreateReceiver(string address); + + + Method: GetSender + + + C++ + Sender getSender(const std::string& name) const; + + + .NET + public Sender GetSender(string name); + + + Method: GetReceiver + + + C++ + Receiver getReceiver(const std::string& name) const; + + + .NET + public Receiver GetReceiver(string name); + + + Property: Connection + + + C++ + Connection getConnection() const; + + + .NET + public Connection Connection { get; } + + + Property: HasError + + + C++ + bool hasError(); + + + .NET + public bool HasError { get; } + + + Method: CheckError + + + C++ + void checkError(); + + + .NET + public void CheckError(); + + + +
+
+
+ .NET Binding Class: SessionReceiver + + The SessionReceiver class provides a convenient callback + mechanism for Messages received by all Receivers on a given + Session. + + + + + + + To use this class a client program includes references to both + Org.Apache.Qpid.Messaging and Org.Apache.Qpid.Messaging.SessionReceiver. + The calling program creates a function that implements the + ISessionReceiver interface. This function will be called whenever + message is received by the session. The callback process is started + by creating a CallbackServer and will continue to run until the + client program calls the CallbackServer.Close function. + + + A complete operating example of using the SessionReceiver callback + is contained in cpp/bindings/qpid/dotnet/examples/csharp.map.callback.receiver. + +
+
+ + + + -- cgit v1.2.1