| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server 3.1 Deployment Planning Guide |
Establishing Performance Goals
Estimating Load on GlassFish Server Instances
Maximum Number of Concurrent Users
Planning the Network Configuration
Estimating Bandwidth Requirements
Calculating Bandwidth Required
Using Clusters to Improve Availability
Adding Redundancy to the System
Designing for Peak or Steady State Load
Sizing the Administration Thread Pool
Planning Message Queue Broker Deployment
Master Broker and Client Synchronization for Conventional Clusters
Configuring GlassFish Server to Use Message Queue Brokers
Managing JMS with the Administration Console
Using a Message Queue Broker Cluster with a GlassFish Server Cluster
Specifying an Application-Specific Message Queue Broker Cluster
The Java Message Service (JMS) API is a messaging standard that allows Java EE applications and components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. Message Queue, which implements JMS, is integrated with GlassFish Server, enabling you to create components that send and receive JMS messages, including message-driven beans (MDBs).
Message Queue is integrated with GlassFish Server using a resource adapter also known as a connector module. A resource adapter is a Java EE component defined according to the Java EE Connector Architecture (JCA) Specification. This specification defines a standardized way in which application servers such as GlassFish Server can integrate with enterprise information systems such as JMS providers. GlassFish Server includes a resource adapter that integrates with its own JMS provider, Message Queue. To use a different JMS provider, you must obtain and deploy a suitable resource adapter that is designed to integrate with it.
Creating a JMS resource in GlassFish Server using the Administration Console creates a preconfigured connector resource that uses the Message Queue resource adapter. To create JMS Resources that use any other resource adapter (including GenericJMSRA), you must create them under the Connectors node in the Administration Console.
In addition to using resource adapter APIs, GlassFish Server uses additional Message Queue APIs to provide better integration with Message Queue. This tight integration enables features such as connector failover, load balancing of outbound connections, and load balancing of inbound messages to MDBs. These features enable you to make messaging traffic fault-tolerant and highly available.
The following topics are addressed here:
Message Queue supports using multiple interconnected broker instances known as a broker cluster. With broker clusters, client connections are distributed across all the brokers in the cluster. Clustering provides horizontal scalability and improves availability.
A single message broker scales to about eight CPUs and provides sufficient throughput for typical applications. If a broker process fails, it is automatically restarted. However, as the number of clients connected to a broker increases, and as the number of messages being delivered increases, a broker will eventually exceed limitations such as number of file descriptors and memory.
Having multiple brokers in a cluster rather than a single broker enables you to:
Provide messaging services despite hardware failures on a single machine.
Minimize downtime while performing system maintenance.
Accommodate workgroups having different user repositories.
Deal with firewall restrictions.
Message Queue allows you to create conventional or enhanced broker clusters. Conventional broker clusters offer service availability. Enhanced broker clusters offer both service and data availability. For more information, see Chapter 10, Configuring and Managing Broker Clusters, in Oracle GlassFish Server Message Queue 4.5 Administration Guide.
In a conventional cluster, having multiple brokers does not ensure that transactions in progress at the time of a broker failure will continue on the alternate broker. Although Message Queue reestablishes a failed connection with a different broker in a cluster, transactions owned by the failed broker are not available until it restarts. Except for failed in-progress transactions, user applications can continue on the failed-over connection. Service failover is thus ensured.
In an enhanced cluster, transactions and persistent messages owned by the failed broker are taken over by another running broker in the cluster and non-prepared transactions are rolled back. Data failover is ensured for prepared transactions and persisted messages.
In a configuration for a conventional broker cluster, each destination is replicated on all of the brokers in a cluster. Each broker knows about message consumers that are registered for destinations on all other brokers. Each broker can therefore route messages from its own directly-connected message producers to remote message consumers, and deliver messages from remote producers to its own directly-connected consumers.
In a cluster configuration, the broker to which each message producer is directly connected performs the routing for messages sent to it by that producer. Hence, a persistent message is both stored and routed by the message’s home broker.
Whenever an administrator creates or destroys a destination on a broker, this information is automatically propagated to all other brokers in a cluster. Similarly, whenever a message consumer is registered with its home broker, or whenever a consumer is disconnected from its home broker—either explicitly or because of a client or network failure, or because its home broker goes down—the relevant information about the consumer is propagated throughout the cluster. In a similar fashion, information about durable subscriptions is also propagated to all brokers in a cluster.
A shared database of cluster change records can be configured as an alternative to using a master broker. For more information, see Chapter 10, Configuring and Managing Broker Clusters, in Oracle GlassFish Server Message Queue 4.5 Administration Guide and Using Message Queue Broker Clusters With GlassFish Server in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
By default, Message Queue brokers (JMS hosts) run in the same JVM as the GlassFish Server process. However, Message Queue brokers (JMS hosts) can be configured to run in a separate JVM from the GlassFish Server process. This allows multiple GlassFish Server instances or clusters to share the same set of Message Queue brokers.
The GlassFish Server’s Java Message Service represents the connector module (resource adapter) for Message Queue. You can manage the Java Message Service through the Administration Console or the asadmin command-line utility.
In GlassFish Server, a JMS host refers to a Message Queue broker. The GlassFish Server’s Java Message Service configuration contains a JMS Host List (also called AddressList) that contains all the JMS hosts that will be used.
There are three types of integration between GlassFish Server and Message Queue brokers: embedded, local, and remote. You can set this type attribute on the Administration Console’s Java Message Service page.
If the Type attribute is EMBEDDED, GlassFish Server and the JMS broker are colocated in the same virtual machine. The JMS Service is started in-process and managed by GlassFish Server. In EMBEDDED mode, JMS operations on stand-alone server instances bypass the networking stack, which leads to performance optimization. The EMBEDDED type is most suitable for stand-alone GlassFish Server instances. EMBEDDED mode is not supported for enhanced broker clusters.
With the EMBEDDED type, use the Start Arguments attribute to specify Message Queue broker startup parameters.
With the EMBEDDED type, make sure the Java heap size is large enough to allow GlassFish Server and Message Queue to run in the same virtual machine.
If the Type attribute is LOCAL, GlassFish Server starts and stops the Message Queue broker. When GlassFish Server starts up, it starts the Message Queue broker specified as the Default JMS host. Likewise, when the GlassFish Server instance shuts down, it shuts down the Message Queue broker. The LOCAL type is most suitable for use with enhanced broker clusters, and for other cases where the administrator prefers the use of separate JVMs.
With the LOCAL type, use the Start Arguments attribute to specify Message Queue broker startup parameters.
If the Type attribute is REMOTE, GlassFish Server uses an externally configured broker or broker cluster. In this case, you must start and stop Message Queue brokers separately from GlassFish Server, and use Message Queue tools to configure and tune the broker or broker cluster. The REMOTE type is most suitable for brokers running on different machines from the server instances (to share the load among more machines or for higher availability), or for using a different number of brokers and server instances.
With the REMOTE type, you must specify Message Queue broker startup parameters using Message Queue tools. The Start Arguments attribute is ignored.
In the Administration Console, you can set JMS properties using the Java Message Service node for a particular configuration. You can set properties such as Reconnect Interval and Reconnect Attempts. For more information, see Chapter 17, Administering the Java Message Service (JMS), in Oracle GlassFish Server 3.1 Administration Guide.
The JMS Hosts node under the Java Message Service node contains a list of JMS hosts. You can add and remove hosts from the list. For each host, you can set the host name, port number, and the administration user name and password. By default, the JMS Hosts list contains one Message Queue broker, called “default_JMS_host,” that represents the local Message Queue broker integrated with GlassFish Server.
In REMOTE mode, configure the JMS Hosts list to contain all the Message Queue brokers in the cluster. For example, to set up a cluster containing three Message Queue brokers, add a JMS host within the Java Message Service for each one. Message Queue clients use the configuration information in the Java Message Service to communicate with Message Queue broker.
In addition to the Administration Console, you can use the asadmin command-line utility to manage the Java Message Service and JMS hosts. Use the following asadmin commands:
Configuring Java Message Service attributes: asadmin set
Managing JMS hosts:
asadmin create-jms-host
asadmin delete-jms-host
asadmin list-jms-hosts
Managing JMS resources:
asadmin create-jms-resource
asadmin delete-jms-resource
asadmin list-jms-resources
For more information on these commands, see Oracle GlassFish Server 3.1-3.1.1 Reference Manual or the corresponding man pages.
You can specify the default JMS Host in the Administration Console Java Message Service page. If the Java Message Service type is LOCAL, GlassFish Server starts the default JMS host when the GlassFish Server instance starts. If the Java Message Service type is EMBEDDED, the default JMS host is started lazily when needed.
In REMOTE mode, to use a Message Queue broker cluster, delete the default JMS host, then add all the Message Queue brokers in the cluster as JMS hosts. In this case, the default JMS host becomes the first JMS host in the JMS host list.
You can also explicitly set the default JMS host to one of the JMS hosts. When the GlassFish Server uses a Message Queue cluster, the default JMS host executes Message Queue-specific commands. For example, when a physical destination is created for a Message Queue broker cluster, the default JMS host executes the command to create the physical destinations, but all brokers in the cluster use the physical destination.
To accommodate your messaging needs, modify the Java Message Service and JMS host list to suit your deployment, performance, and availability needs. The following sections describe some typical scenarios.
For best availability, deploy Message Queue brokers and GlassFish Servers on different machines, if messaging needs are not just with GlassFish Server. Another option is to run a GlassFish Server instance and a Message Queue broker instance on each machine until there is sufficient messaging capacity.
Installing the GlassFish Server automatically creates a domain administration server (DAS). By default, the Java Message Service type for the DAS is EMBEDDED. So, starting the DAS also starts its default Message Queue broker.
Creating a new domain also creates a new broker. By default, when you add a stand-alone server instance or a cluster to the domain, its Java Message Service is configured as EMBEDDED and its default JMS host is the broker started by the DAS.
In EMBEDDED or LOCAL mode, when a GlassFish Server is configured, a Message Queue broker cluster is auto-configured with each GlassFish Server instance associated with a Message Queue broker instance.
In REMOTE mode, to configure a GlassFish Server cluster to use a Message Queue broker cluster, add all the Message Queue brokers as JMS hosts in the GlassFish Server’s Java Message Service. Any JMS connection factories created and MDBs deployed then uses the JMS configuration specified.
In some cases, an application may need to use a different Message Queue broker cluster than the one used by the GlassFish Server cluster. To do so, use the AddressList property of a JMS connection factory or the activation-config element in an MDB deployment descriptor to specify the Message Queue broker cluster.
For more information about configuring connection factories, see Administering JMS Connection Factories and Destinations in Oracle GlassFish Server 3.1 Administration Guide. For more information about MDBs, see Using Message-Driven Beans in Oracle GlassFish Server 3.1 Application Development Guide.
When an application client or standalone application accesses a JMS administered object for the first time, the client JVM retrieves the Java Message Service configuration from the server. Further changes to the JMS service will not be available to the client JVM until it is restarted.
|