Clustering and Destinations

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.

• Producing to a Queue Using the Reply-To Model

• Producing to an Auto-Created Destination

• Publishing to a Topic Destination

• Handling Destinations in the Event of Connection or Broker Failure

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–3 Replication of Destinations in a Cluster: Queue with Reply-To

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

2. 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.)

3. 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–4 Replication of Destinations in a Cluster: Auto-Created Destinations

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

2. 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–5 Replication of Destinations in a Cluster: Publishing to a Topic

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

2. Publisher PubTY, sends a message to topicTY.

3. 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.  Using the conventional cluster model, 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.  Using the high availability cluster model, information synchronized using the shared persistent store.
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. In this case, 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.