Configuration Reload

The system will perform a periodic check on the configuration files, configured by configuration-file-refresh-period, with the default at 5000, in milliseconds. These checks can be disabled by specifying -1.

Once the configuration file is changed (broker.xml) the following modules will be reloaded automatically:

• Address Settings
• Security Settings
• Diverts
• Addresses & Queues
• Bridges

If using modulised broker.xml ensure you also read Reloading modular configuration files

Note:

Deletion of Address’s Queue’s and diverts not auto created is controlled by Address Settings

• config-delete-addresses

  • OFF (DEFAULT) - will not remove upon config reload.
  • FORCE - will remove the address and its queues upon config reload, even if messages remains, losing the messages in the address & queues.

• config-delete-queues

  • OFF (DEFAULT) - will not remove upon config reload.
  • FORCE - will remove the queue upon config reload, even if messages remains, losing the messages in the queue.

• config-delete-diverts

  • OFF (DEFAULT) - will not remove upon config reload.
  • FORCE - will remove the queue upon config reload, even if messages remains, losing the messages in the queue.

By default both settings are OFF as such address & queues won’t be removed upon reload, given the risk of losing messages.

When OFF You may execute explicit CLI or Management operations to remove address & queues.

Reloadable Parameters

The broker configuration file has 2 main parts, <core> and <jms>. Some of the parameters in the 2 parts are monitored and, if modified, reloaded into the broker at runtime.

Note: Elements under <jms> are deprecated. Users are encouraged to use <core> configuration entities.

Note:

Most parameters reloaded take effect immediately after reloading. However there are some that won’t take any effect unless you restarting the broker. Such parameters are specifically indicated in the following text.

<core>

<security-settings>

• <security-setting> element

Changes to any <security-setting> elements will be reloaded. Each <security-setting> defines security roles for a matched address.

• The match attribute

  This attribute defines the address for which the security-setting is defined. It can take wildcards such as ‘#’ and ‘*’.

• The <permission> sub-elements

Each <security-setting> can have a list of <permission> elements, each of which defines a specific permission-roles mapping. Each permission has 2 attributes ‘type’ and ‘roles’. The ‘type’ attribute defines the type of operation allowed, the ‘roles’ defines which roles are allowed to perform such operation. Refer to the user’s manual for a list of operations that can be defined.

Note:

Once loaded the security-settings will take effect immediately. Any new clients will subject to the new security settings. Any existing clients will subject to the new settings as well, as soon as they performs a new security-sensitive operation.

Below lists the effects of adding, deleting and updating of an element/attribute within the <security-settings> element, whether a change can be done or can’t be done.

• N/A means this operation is not applicable.
• X means this operation is not allowed.

<address-settings>

• <address-settings> element

Changes to elements under <address-settings> will be reloaded into runtime broker. It contains a list of <address-setting> elements.

• <address-setting> element

  Each address-setting element has a ‘match’ attribute that defines an address pattern for which this address-setting is defined. It also has a list of sub-elements used to define the properties of a matching address.

  Note:

  Parameters reloaded in this category will take effect immediately after reloading. The effect of deletion of Address’s and Queue’s, not auto created is controlled by parameter config-delete-addresses and config-delete-queues as described in the doc.

Below lists the effects of adding, deleting and updating of an element/attribute within the address-settings element, whether a change can be done or can’t be done.

<diverts>

All <divert> elements will be reloaded. Each <divert> element has a ‘name’ and several sub-elements that defines the properties of a divert.

Note:

Existing diverts get undeployed if you delete their <divert> element.

Below lists the effects of adding, deleting and updating of an element/attribute within the diverts element, whether a change can be done or can’t be done.

<addresses>

The <addresses> element contains a list <address> elements. Once changed, all <address> elements in <addresses> will be reloaded.

Note:

Once reloaded, all new addresses (as well as the pre-configured queues) will be deployed to the running broker and all those that are missing from the configuration will be undeployed.

Note:

Parameters reloaded in this category will take effect immediately after reloading. The effect of deletion of Address’s and Queue’s, not auto created is controlled by parameter config-delete-addresses and config-delete-queues as described in this doc.

Below lists the effects of adding, deleting and updating of an element/attribute within the <addresses> element, whether a change can be done or can’t be done.

<queue>

Changes to any <queue> elements will be reloaded to the running broker.

Note:

Once reloaded, all new queues will be deployed to the running broker and all queues that are missing from the configuration will be undeployed.

Note:

Parameters reloaded in this category will take effect immediately after reloading. The effect of deletion of Address’s and Queue’s, not auto created is controlled by parameter config-delete-addresses and config-delete-queues as described in this doc.

Below lists the effects of adding, deleting and updating of an element/attribute within the <queue> element, and whether a change can be done or can’t be done.

<jms> (Deprecated)

<queues> (Deprecated)