0.13 Broker config.xml details

Major changes from earlier versions

Here are the major changes required to config.xml from earlier versions:

1. Authentication Manager

  • It is now required that an single authentication manager is plugged in within the broker/security section.  This element replaces the old security/principal-databases and security/jmx sections. In future it will allow for authentication to be delegated to a third party system (i.e. an Enterprise Directory).

File Format

This is an overview of the top level of the config file. Description of each section is embedded below. Each section is then described in detail in their own section..

<broker>
    <connector>
<!-- Type of connections and properties -->
    <management>
<!-- Enablement of management functionality -->
    <advanced>
<!-- Various advanced flags -->
    <security>
<!-- Definition of available security options -->
    <virtualhosts>
<!-- Definition of available virtual hosts -->
    <heartbeat>
<!-- Heartbeat configuration -->
    <queue>
<!-- General queue configuration options-->
    <virtualhosts>
<!-- Configuration of various virtual hosts. -->
</broker>

Configuration Sections - Detailed Information

The following sections provide an element by element overview of the config.xml.

Broker

The setting of the prefixes for QPID_HOME and QPID_WORK allows environment variables to be used throughout the config.xml and removes the need for hard coding of paths in this file.

See the Environment Variables section of the Getting Started Guide for more information on these variables.

<broker>
    <prefix>${QPID_HOME}</prefix>
    <work>${QPID_WORK}</work>
    <conf>${prefix}/etc</conf>
    <plugin-directory>${QPID_HOME}/lib/plugins</plugin-directory>
    <cache-directory>${QPID_WORK}/cache</cache-directory>

Connector

The connector section allows configuration of SSL and related keystore settings. By default this section is commented out and thus SSL is not enabled.

<connector>
    <!-- Uncomment out this block and edit the keystorePath and keystorePassword
         to enable SSL support
    <ssl>
        <enabled>true</enabled>
        <sslOnly>true</sslOnly>
        <keystorePath>/path/to/keystore.ks</keystorePath>
        <keystorePassword>keystorepass</keystorePassword>
    </ssl>-->
    <port>5672</port>
    <sslport>8672</sslport>
    <socketReceiveBuffer>262144</socketReceiveBuffer>
    <socketSendBuffer>262144</socketSendBuffer>
</connector>

Management

This element allows the user to switch the connectivity of the management console on/off i.e. if the enabled tag is set to false you will not be able to connect a management console to this broker instance. The JMX Management port is set to 8999 by default but it can be changed here in the XML or on the command line. The management console has the ability to utilise some additional Sun Binary Code License code to improve the security of JMX Connections. Full details of this can be found here.

<management>
    <enabled>true</enabled>
    <jmxport>8999</jmxport>
    <ssl>
        <enabled>false</enabled>
        <!-- Update below path to your keystore location, or run the bin/create-example-ssl-stores(.sh|.bat)
             script from within the etc/ folder to generate an example store with self-signed cert -->
        <keyStorePath>${conf}/qpid.keystore</keyStorePath>
        <keyStorePassword>password</keyStorePassword>
    </ssl>
</management>

Advanced

The elements in this section are used under the covers in the broker. At present, we do not recommend any changes to these settings.

<advanced>
   <filterchain enableExecutorPool="true"/>
   <framesize>65535</framesize>
   <enableJMSXUserID>false</enableJMSXUserID>
   <locale>en_US</locale>
</advanced>

Security

The security section specifies exactly one authentication manager (responsible for determining that a user's credentials are correct) and zero or more access plugins (limits what the user may and may not do).  See also Configure ACLs and Firewall Configuration

<security>
    <!-- Exactly one auth-manager must be defined -->
    <pd-auth-manager>
        <!-- pd-auth-manager authenticates against a password file in the filesystem -->
        <principal-database>
            <!-- The type of flat file -->
            <class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class>
            <!-- Any attributes associated with the database. Here it is a password file to load. -->
            <attributes>
                <attribute>
                    <name>passwordFile</name>
                    <value>${conf}/passwd</value>
                </attribute>
            </attributes>
        </principal-database>
    </pd-auth-manager>
    <!-- Zero or more access managers e.g. firewall, aclv2, allow-all etc -->
    <allow-all />
</security>

Virtualhosts

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. NB: The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

In our example config.xml, we define three virtual hosts which we commonly use for development (development), system testing (test) and integration testing (localhost). In the config.xml the per virtual host sections define both the Message Store in use (MemoryMessageStore for non-persistent applications or BDBMessageStore for persistent application usage) and zero or more access plugins.

The default virtual host for connections which do not specify a host on the url is 'test' in the example config.xml.

<virtualhost>
            <name>localhost</name>
            <localhost>
                <store>
                    <!-- <class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
                    <environment-path>${work}/localhost-store</environment-path> -->

                    <class>org.apache.qpid.server.store.MemoryMessageStore</class>
                </store>
            </localhost>
</virtualhost>

Heartbeat

The Qpid broker sends an internal (only) heartbeat. This element allows configuration of the frequency of this heartbeat. At present, we recommend that you leave this section unchanged !

<heartbeat>
    <delay>0</delay>
    <timeoutFactor>2.0</timeoutFactor>
</heartbeat>

Queue

This should NOT be changed lightly as it sets the broker up to automatically bind queues to exchanges.

It could theoretically be used to prevent users creating new queues at runtime, assuming that you have created all queues/topics etc at broker startup. However, best advice is to leave unchanged for now.

<queue>
    <auto_register>true</auto_register>
</queue>

Virtualhosts

This element allows you to specify a location for the virtualhosts.xml file that you wish to use. If you are not using a subdirectory under $QPID_HOME you can provide a fully qualified path instead. For more information on the content of the virtualhosts.xml file please see Configure the Virtual Hosts via virtualhosts.xml

<virtualhosts>${conf}/virtualhosts.xml</virtualhosts>
  • No labels