This chapter describes how to configure Virtual Hosts using an XML file. This is no longer the preferred approach for defining a VirtualHost and will likely be removed in a future release, however it is currently neccessary to support certain use cases such as per-virtualhost attribute configuration, and specialised store configuration such as for the BDB HA Message Store Each XML Virtual Host configuration file can hold configuration for a single Virtual Host or multiple Virtual Hosts. For an example file (with multiple VirtualHosts), see

provides the details of ACL, rules, formats, etc. To apply an ACL on a single virtualhost named test, add the following to the virtualhosts.xml: <virtualhost> ... <name>test</name> <test> ... <security> ... <acl>${conf}/vhost_test.acl</acl> ... </security> ... </test> </virtualhost> A security section of configuration is used to declare the ACL A path to an ACL file is configured (assuming that conf has been set to a suitable location such as ${QPID_HOME}/etc)

An example of MemoryMessageStore configuration for a virtual host is shown below: vhostname org.apache.qpid.server.store.MemoryMessageStore ... ]]>

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. vhostname org.apache.qpid.server.store.berkeleydb.BDBMessageStore ${QPID_WORK}/bdbstore/vhostname ... ]]>

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. vhostname org.apache.qpid.server.store.DerbyMessageStore ${QPID_WORK}/derbystore/vhostname ... ]]>

JDBCMessageStore can be configured on VirtualHost as in example shown below: vhostname org.apache.qpid.server.store.jdbc.JDBCMessageStore jdbc:oracle:thin:guest@guest//localhost:1521/orcl ... ]]>

To declare Exchanges within Virtual Host configuration, add the appropriate xml to the virtualhost.xml configuration file within the exchanges element. An example of such declaration is shown below: vhostname ... direct test.direct true topic test.topic ... ]]>

To create a priority, sorted or LVQ queue within configuration, add the appropriate xml to the virtualhost.xml configuration file within the queues element.

For declaration of a simple queue define a queue entry in the virtual host configuration as in example below my-simple-queue amq.direct true ]]>

To defining a priority queue, add a <priority>true</priority> element. By default the queue will have 10 distinct priorities. 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". myqueue amq.direct true 4 ]]>

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. myqueue amq.direct message-property-to-sort-by ]]>

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. myqueue amq.direct true ]]> If you wish to define your own property then you can do so using the lvqKey element. myqueue amq.direct true ISIN ]]>

Flow control capacity and flow resume capacity are required to set on a queue or virtual host to enable Producer flow control. test amq.direct 10485760 8388608 ]]> The default for all queues on a virtual host can also be set localhost 10485760 8388608 ]]>

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 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: 10000 20000 5000 15000 ]]>

In the below configuration it can be seen that DLQs/Maximum Delivery Count are enabled at the virtual host "localhost" with maximum delivery count set to 5 and disable for virtual host "dev-only". 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 disabled. Any other queue in the 'localhost' virtualhost which does not specify its own configuration value will have the features enabled (inherited from parent virtual host). ... dev-only false 0 dev-only-main-queue true 3 dev-only-other-queue localhost true 5 localhost-queue false ... ]]>

localhost org.apache.qpid.server.store.MemoryMessageStore 2 20000 direct test.direct true topic test.topic amq.direct 4235264 2117632 600000 50 queue ping test-queue test.direct true test-ping test.direct development org.apache.qpid.server.store.MemoryMessageStore 30000 50 queue amq.direct 4235264 2117632 600000 ping amq.direct 4235264 2117632 600000 test org.apache.qpid.server.store.derby.DerbyMessageStore ${QPID_WORK}/derbystore/test 30000 50 queue amq.direct 4235264 2117632 600000 ping amq.direct 4235264 2117632 600000 ]]>