In a cluster configuration using either model, 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.
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. This behavior is the same for both clustering models. 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 |
Global |
maxNumProducers |
Per broker |
maxNumActiveConsumers |
Global |
maxNumBackupConsumers |
Global |
consumerFlowLimit |
Global |
localDeliveryPreferred |
Global |
isLocalOnly |
Global |
useDMQ |
Per broker |
How a destination is created (by an administrator, automatically, or as a temporary destination) determines how the destination is propagated in a cluster and how it is handled in the event of connection or broker failure. This behavior is the same for both cluster models. The following subsections examine a few use cases to determine when a destination is created and how it's replicated. These include the following.
The figure below shows how destinations are created and replicated when a client produces to a queue and uses the reply-to model.
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.
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.
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.
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.
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.
Table 4–2 explains how different kinds of destinations are replicated and deleted in a cluster.
Table 4–2 Handling Destinations in a Cluster