BlazingMQ Configuration

• Broker Configuration
• Cluster Configuration
• Domain Configurations
  • Domain Definition
  • Domain Redirection

BlazingMQ is a highly flexible system, with the BlazingMQ message broker at its core. A broker, or node, participates in a cluster, which manages a collection of domains. This leads to three configurable entities in the system – BlazingMQ message broker, BlazingMQ cluster and BlazingMQ domain. Configurations for all of them are expressed as a set of JSON files, located in a directory passed to message broker process (bmqbrkr) on the command line.

The structure of the directory is:

• root/
  • bmqbrkrcfg.json
  • clusters.json
  • domains/
    • domain1.json
    • domain2.json
    • …

Broker Configuration

bmqbrkrcfg.json contains configuration that is specific to an instance of the broker, i.e. a single process running bmqbrkr. It specifies various low-level parameters, like number of worker threads, initial size of memory pools, the location and the format of the log files, etc.

The more important parameters in this file are:

• appConfig/hostName
  The name of the host, as it will appear in the cluster configuration file. Can be overriden on the command line with -h or --hostName.

• appConfig/brokerInstanceName
  The name of the broker instance, used to identify a broker if more than one broker runs on the same host. Set to “default” otherwise. Can be overriden on the command line with -i or --instanceId.

• appConfig/hostDataCenter
  The name of the “data center” of the host. In some circumstances, a broker will prefer to use a connection with another broker in the same data center, for performance. Can be overriden on the command line with -d or --hostDataCenter.

• appConfig/hostDataCenter/networkInterfaces/tcpInterface/port
  The port that the broker listens to. Can be overriden on the command line with -p or --port.

For a complete list of settings, see the configuration schema. The top level object is Configuration. For a sample configuration, see the Docker example.

Cluster Configuration

clusters.json specifies all the clusters known to the broker. It contains two optional keys - myClusters and proxyClusters. The associated values are arrays of objects. Either keys are optional, and either arrays can be empty, but not at the same time.

The objects in the myClusters array each specify a cluster that a broker instance is a member, or node, of. They consist of:

• name
  The name of the cluster.

• nodes
  An array of objects describing the nodes in the cluster. They consist of:
  • name
    The name of the node.
  • id
    An integer node identifier, unique within the cluster.
  • dataCenter
    The data center of the node. Proxies will use connections to brokers in the same data center, if available.
  • transport/tcp/endpoint
    A string in the form "tcp://{hostName}:{port}"

• partitionConfig
  Specifies the location of the partitions used to store the messages, maximum file sizes, whether to pre-allocate and prefault storage, etc.

• elector
  Settings for the leader election subsystem: quorum, maximum attempts to open a queue, and various timeouts.

• queueOperations
  Settings for queue operations (mostly timeouts).

• clusterMonitorConfig
  Controls how long transitional cluster states can perdure before raising an alert in the broker logs.

• messageThrottleConfig
  Sets limits on the rate at which a producer can post messages.

The objects in the proxyClusters array specify the clusters the broker can proxy to. They are similar to the myClusters objects, but they lack the masterAssignment, partitionConfig and elector keys.

For a complete list of settings, see the configuration schema. The top level object is ClustersDefinition. For a sample configuration, see the Docker example.

Domain Configurations

Each file corresponds to one BlazingMQ domain that the broker can handle. It contains either a definition or a redirection. For a complete list of settings, see the schema. The top level object is DomainVariant. For sample configurations, see the Docker example.

Domain Definition

The more important parameters in the definition object are:

• definition/location
  The name of the cluster to contact to open a queue in the domain. It must be a name listed in the myClusters section of clusters.json, in which case the broker handles the request; or a name listed in proxyClusters, in which case the broker forwards the request.

• definition/parameters/mode
  The queue mode, either priority, broadcast, or fanout.

• definition/parameters/maxDeliveryAttempts
  The maximum number of times the cluster should attempt to deliver the same message. Any value other than zero enables poison pill detection.

• definition/parameters/consistency
eventual or strong. Select the consistency model.

• definition/parameters/storage/config
fileBacked or inMemory. Specifies whether messages are kept on disk (typical for priority and fanout domains), or in memory (required for broadcast domains, allowed for 1-node clusters).

• definition/parameters/mode/fanout/appIDs
  For fanout mode only, a list of appId names.

The other parameters configure per-domain and per-queue message and byte quotas, maxima for the number of producers, consumers, and queues, etc.

Domain Redirection

Redirection is similar to a symbolic link, i.e. it gives an additional name to an existing domain. Unlike symlinks, only one level of redirection is allowed, and it is performed only by the first broker that handles the open queue request.

A redirection consists of a single key-value pair: redirect and the new domain name.