Message Delivery

In a cluster configuration, brokers share information about destinations
and message consumers: each broker knows the following information”

The name, type, and attributes of all physical destinations
in the cluster

The name, location, and interests of each message consumer

Updates (deletions, additions, or reconfiguration) to the
above

This allows each broker to route messages from its own directly connected
message producers to remote message consumers. The home broker of a producer
has different responsibilities from the home broker of the consumer:

The producer’s home broker is responsible for persisting
and routing messages originating from that producer, for logging, for managing
transactions, and for processing acknowledgements from consuming clients.

The consumer’s home broker is responsible for persisting
information about consumers, for forwarding the message to the consumer, and
for letting the producer’s broker know whether the consumer is still
available and whether the message was successfully consumed.

Clustered brokers work together to minimize message traffic within the
cluster; for example, if a remote broker has two identical subscriptions for
the same topic destination, the message is sent over the wire only once. You
can further reduce traffic by setting a destination property specifying that
delivery to local consumers has priority over delivery to remote consumers.

If secure, encrypted message delivery between client and broker is required,
you can configure a cluster to provide secure delivery of messages between
brokers.

Destination Attributes

Attributes set for a physical destination on a clustered broker apply
to all instances of that destination in the cluster; however, some limits
specified by these attributes apply to the cluster as a whole and others to
individual destination instances. Table 4–1 lists
the attributes you can set for a physical destination and specifies their
scope.

Table 4–1 Properties for Physical
Destinations on Clustered Brokers

Property Name

Scope

maxNumMsgs

Per broker. Thus, distributing producers across a cluster, allows you
to raise the limit on total unconsumed messages.

maxTotalMsgBytes

Per broker. Thus, distributing producers across a cluster, allows you
to raise the limit on total memory reserved for unconsumed messages.

lmitBehavior

Global

maxBytesPerMsg

Per broker

maxNumProducers

Per broker

maxNumActiveConsumers

Global

maxNumBackupConsumers

Global

consumerFlowLimit

Global

localDeliveryPreferred

Global

isLocalOnly

Global

useDMQ

Per broker

Clustering and Destinations

Whether a destination is created by an administrator, is created automatically,
or is temporary, affects how the destination is propagated in a cluster and
how it is handled in the event of connection or broker failure. The following
subsections examine a few use cases to determine when a destination is created
and how it's replicated. These include:

Producing to a Queue Using the Reply-To Model

The figure below shows how destinations are created and replicated when
a client produces to a queue and uses the reply-to model.

Figure 4–2 Replication of Destinations in a Cluster: Queue
with Reply-To

The administrator creates the physical destination QW.
The queue is replicated throughout the cluster at creation time.

Producer ProdQW sends a message to queue QW and uses the reply-to model, directing replies to temporary queue TempQ1W. (The temporary queue is created and replicated when an
application creates a temporary destination and adds a consumer.)

The home broker, BrokerW, persists the
message sent to QW and routes the message to the first
active consumer that meets the selection criteria for this message. Depending
on which consumer is ready to receive the message, the message is delivered
either to consumer C1QW (on BrokerX)
or to consumer C2QW (on BrokerZ).
The consumer receiving the message, sends a reply to the destination TempQ1W.

Producing to an Auto-Created Destination

The next figure shows how destinations are created and replicated in
the case of a producer that sends a message to a destination that does not
exist and has to be automatically created.

Figure 4–3 Replication of Destinations in a Cluster: Auto-Created
Destinations

Producer ProdAutoQY sends a message to
a destination AutoQY that does not exist on the broker.

The broker persists the message and creates destination AutoQY.

Auto-created destinations are not automatically
replicated across the cluster. Only when a consumer elects to receive messages
from a queue AutoQY, would that consumer’s home broker
create the destination AutoQY and convey the message to
the consumer. At the point where one consumer creates the autocreated destination,
the destination is replicated across the cluster. In this example, when the
consumer CAutoQY, creates the destination, the replication
takes place.

Publishing to a Topic Destination

The following figure shows how destinations are created and replicated
in a cluster when a client publishes a message to a topic destination that
is created by the administrator.

Figure 4–4 Replication of Destinations in a Cluster: Publishing
to a Topic

The administrator creates the physical topic destination TY. The admin-created destination TY is replicated
throughout the broker cluster (before the destination is used).

Publisher PubTY, sends a message to topicTY.

The home broker, BrokerY, persists any
messages published to TY and routes the messages to all
topic subscribers that match the selection criteria for this message. In this
example C1TY and C2TY are subscribed
to topicTY.

Handling Destinations in the Event of Connection
or Broker Failure

Table 4–2 explains how different
kinds of destinations are replicated and deleted in a cluster.

Table 4–2 Handling Destinations
in a Cluster

Destination

Propagation, and Deletion

Admin-created

When the destination is created it is propagated in the cluster, and
each broker stores information about the destination persistently.

The destination is destroyed when the administrator explicitly deletes
it.

If there is a master broker, a record of the creation and deletion is
stored in the master broker to allow brokers in the cluster to synchronize
state information.

Temporary

When the destination is created, it is propagated around the cluster.

If the consumer associated with the temporary destination is allowed
to reconnect, the destination is persistently stored on the consumer’s
home broker. Otherwise, the destination is never stored.

If the consumer loses its connection, the destination is deleted on
all brokers.

If the consumer’s home broker crashes and the consumer is allowed
to reconnect, temporary destinations associated with this consumer are monitored.
If the consuming client does not reconnect within a specific period of time,
it is assumed that the client has failed and the destination is deleted.

Auto-created

When a producer is created and a destination does not exist, the destination
is created on the producer’s home broker.

When a consumer is created for a destination that does not exist, information
about the consumer and the destination is propagated across the cluster.

An auto-created destination can be explicitly deleted by an administrator,
or it can be automatically deleted

By each broker when there have been no consumers or messages
for a given period of time.

By each broker, when the broker restarts and there are no
messages for that destination.