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 --- .../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 97 files changed, 4855 insertions(+), 6964 deletions(-) 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 (limited to 'doc/book/src/java-broker') 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 -- cgit v1.2.1