JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Technical Overview
search filter icon
search icon

Document Information


1.  Messaging Systems: An Introduction

2.  Client Programming Model

3.  The Message Queue Broker

4.  Broker Clusters

Cluster Models

Cluster Message Delivery

Propagation of Information Across a Cluster

Message Delivery Mechanisms

Conventional Clusters

Enhanced Clusters

Cluster Models Compared

Cluster Configuration

5.  Message Queue and Java EE

A.  Message Queue Implementation of Optional JMS Functionality

B.  Message Queue Features



Cluster Models Compared

Conventional and enhanced cluster models share the same basic infrastructure. They both use the cluster communication service to enable message delivery between producers and consumers across the cluster. However, as shown in the following figure and described in previous sections, these models differ in how destination and consumer information is synchronized across the cluster, in the mechanisms for detecting failure, in how client reconnect takes place.

Figure 4-5 Cluster Infrastructure

image:Diagram comparing conventional and enhanced broker cluster infrastructures. Figure explained in the text.

In addition, while both models rely on the broker's persistence interfaces (both flat-file and JDBC), in the case of enhanced clusters the shared data store must be a highly-available JDBC database (a highly-available file-based data store has not yet been implemented).

The following table summarizes the functional differences between the two cluster models. This information might help in deciding which model to use or whether to switch from one to another.

Table 4-1 Clustering Model Differences

Faster than enhanced cluster model.
Slower than conventional cluster model.
Service availability
Yes, but some operations are not possible if master broker is down.
Data availability
No. State information in failed broker is not available until broker restarts.
Yes at all times.
Recovery at failover
No. Persistent messages and states are unavailable until the failed broker restarts. Also, client reconnects might not be possible if failure occurs during a transaction commit (rare).
Yes. Persistent messages and states in failed broker are taken over, non-prepared transactions are rolled back, and messages are processed for delivery. If failure occurs during a transaction commit, an exception might be thrown indicating that the transaction could not be committed (extremely rare).
Set appropriate cluster configuration properties for each broker.
Set appropriate cluster configuration properties for each broker.
Additional requirements
Highly-available database.
Restricted to subnet