Weblogic JMS advanced Topic

Oracle WLS JMS Server

JMS servers are configuration entities that act as management containers for the JMS queues and topics in JMS modules that are targeted to specific JMS servers. A JMS server is configured and targeted to a server. There can be multiple JMS servers targeted to the same Oracle WebLogic Server instance.

The configuration of JMS servers is in the domain’s config.xml file. Multiple JMS servers can be configured as long as they are uniquely named. Each JMS server handles requests for all targeted modules’ destinations. Requests for destinations that are not handled by a JMS server are forwarded to the appropriate server instance.

A JMS server’s primary responsibility for its destinations is to maintain information about the persistent store that is used for any persistent messages that arrive on the destinations and to maintain the states of the durable subscribers created on the destinations. JMS servers also manage message paging on destinations. Optionally, they can manage message and/or byte thresholds, as well as server-level quota for their targeted destinations. Because it is a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all the destinations that it hosts. 

Creating a JMS Server

You can create and configure a JMS server by using the Administration Console. To create a JMS server, perform the following steps: 

1.  Expand the Services node in Domain Structure in the left panel, and then expand the Messaging node. Click JMS Servers. The summary of JMS servers appears in the right pane.

2.  Click Lock & Edit to enable editing configuration. Then click New at the JMS Servers table. The “Create a New JMS Server” dialog box appears.

3.  Enter values for the following configuration parameters:

-Name: The name of the JMS server

-Persistent Store: The backing store used by destinations. A value of none means that the JMS server will use the default persistent store that is configured on each targeted WLS instance.

4.  Click Next to target a JMS server.

5.  When you specify that you want to create a new store in step 3, the “Select store type” page appears. You can select File Store or JDBC Store.

-If you specify File Store, the “File store properties” page appears. When creating a file store for the JMS Persistent store, the path name to the directory must exist on your system, so be sure to create it before completing this page.

-If you selected JDBC Store, in the “Create new JDBC Store” page, select a configured JDBC data source or configure a new JDBC data source for the store. You cannot configure a JDBC data source that is configured to support global transactions.

Configuring a JMS Server

You can change the configuration of already created JMS servers or add configurations on a JMS server by performing the following steps:

1.  Select Services > Messaging > JMS Servers from the Domain Structure pane. Locate and click the link to the JMS server that you want to configure.

2.  Enter the values appropriately in the “Settings for the JMS server” page. 

You can set persistent stores at the time of creating a JMS server. If you have already configured persistent stores, you can assign one of them when configuring the JMS server.

Targeting a JMS Server to a Managed Server

When the JMS server that you created is selected in the left pane, a dialog box appears in the right pane showing the tabs that are associated with this instance.

1.  Select a target from the Target drop-down list.
(Note: A JMS server can be targeted to only one WebLogic Server.)

2.  Click Finish.

 

JMS Modules

JMS modules are application-related definitions that are independent of the domain environment. You create and manage JMS resources either as system modules or application modules.

•JMS system modules are typically configured using the Administration Console or the WebLogic Scripting Tool (WLST), which adds a reference to the module in the domain’s config.xml file. System modules are owned and modified by the WebLogic administrator and are available to all applications.

•JMS application modules are a WebLogic-specific extension of Java EE modules and can be deployed either with a Java EE application (as a packaged resource) or as stand-alone modules that can be made globally available. Application modules are owned and modified by WebLogic developers, who package JMS resource modules with the application’s EAR file.

After the initial deployment is completed, an administrator has only limited control over the deployed applications. For example, administrators are allowed only to ensure the proper life cycle of these applications (deploy, undeploy, redeploy, remove, and so on) and tune parameters, such as increasing or decreasing the number of instances of any given application to satisfy the client needs. Other than life cycle and tuning, any modification to these applications must be completed by the application development team.

During the process of deploying a JMS application, you link the application components to the environment-specific JMS resource definitions, such as the server instances (deployment target) that should host a given application component, and the location to use for persisting JMS messages.

With modular deployment of JMS resources, you can migrate your application and the required JMS configuration from environment to environment, such as from a testing environment to a production environment, without opening an enterprise application file (such as an EAR file) or a stand-alone JMS module, and without extensive manual JMS reconfiguration.

JMS configuration resources, such as destinations and connection factories, are stored outside of the WebLogic domain configuration file as module descriptor files, which conform to the weblogic-jms.xsd schema. JMS modules do not include the JMS server definitions.

The JMS system modules must be targeted to one or more Oracle WebLogic Server instances or to a cluster. The targetable resources that are defined in a system module must also be targeted to a JMS server or the Oracle WebLogic Server instances within the scope of a parent module’s targets. Additionally, the targetable JMS resources within a system module can be further grouped into subdeployments during the configuration or targeting process to provide further loose-coupling of the JMS resources in a WebLogic domain.

Modular JMS Resource Configuration and Deployment

A subdeployment for JMS destinations is a mechanism by which queues and topics, and possibly connection factories, are grouped and targeted to a single JMS server. Queues and topics depend on the JMS servers they are targeted to for the management of persistent messages, durable subscribers, and message paging. To reconfigure a subdeployment’s targets, use the parent system module’s subdeployment management page.

For example, if you want to co-locate a group of queues with a connection factory that is targeted to a specific JMS server, you can associate the queues with the subdeployment that the connection factory belongs to, provided that the connection factory is not already targeted to multiple JMS servers (for example, targeted to a server instance hosting multiple JMS servers).

Creating Packaged JMS Modules: You create packaged JMS modules using an enterprise-level integrated development environment (IDE) or a development tool that supports the editing of XML descriptor files. You then deploy and manage stand-alone modules using the JSR 88–based tools, such as the weblogic.Deployer utility or the WebLogic Administration Console.

Deploying a Packaged JMS Module: The deployment of packaged JMS modules follows the same model as all the other components of an application: individual modules can be deployed to a single server, a cluster, or individual members of a cluster.

Connection Factories

Connection factories are resources that enable JMS clients to create JMS connections. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously. WebLogic JMS provides preconfigured default connection factories that can be enabled or disabled on a per-server basis. You can also configure one or more connection factories to create connections with predefined options that better suit your application.

Some connection factory options are dynamically configurable. You can modify the following parameters for connection factories:

•General configuration parameters, including modifying the default client parameters, default message delivery parameters, load-balancing parameters, unit-of-order parameters, and security parameters

•Transaction parameters, which enable you to define a value for the transaction timeout option and to indicate whether an XA queue or XA topic connection factory is returned, and whether the connection factory creates sessions that are XA-aware

•Flow control parameters, which enable you to tell a JMS server or a destination to slow down message producers when it determines that it is becoming overloaded

When connection factory options are modified at run time, only the incoming messages are affected; stored messages are not affected.

Within each JMS module, the connection factory resource names must be unique. All connection factory JNDI names in any JMS module must be unique across an entire WebLogic domain. Oracle WebLogic Server adds the connection factory names to the JNDI space during startup, and the application then retrieves a connection factory using the WebLogic JNDI APIs.

You can establish clusterwide, transparent access to JMS destinations from any server in the cluster, either by using the default connection factories for each server instance or by configuring one or more connection factories and targeting them to one or more server instances in the cluster. This way, each connection factory can be deployed on multiple Oracle WebLogic Server instances.

Using a Default Connection Factory

Oracle WebLogic Server defines two default connection factories, which can be looked up using the following JNDI names:

•weblogic.jms.ConnectionFactory

•weblogic.jms.XAConnectionFactory

You need to configure a new connection factory only if the preconfigured settings of the default factories are not suitable for your application. The main difference between the preconfigured settings for the default connection factories and a user-defined connection factory is the default value for the XA Connection Factory Enabled option to enable JTA transactions. Also, using default connection factories means that you have no control over targeting the Oracle WebLogic Server instances where the connection factory may be deployed. However, you can enable or disable the default connection factories on a per-Oracle WebLogic Server basis.

Creating a Connection Factory

Within each JMS module, the connection factory resource names must be unique. All the connection factory JNDI names in any JMS module must be unique across an entire WebLogic domain.

1.  In the Administration Console, expand Services > Messaging, and click JMS Modules. Select an existing JMS module.

2.  In the Summary of Resources table click New.

3.  Select the Connection Factory resource type and click Next.

4.  (Not shown) Enter Name and JNDI Name for the new connection factory, and click Next.

5.  (Not shown) For basic default targeting, accept the default targets that are presented in the Targets box, and then click Finish. For advanced targeting, click Advanced Targeting, which allows you to select an existing subdeployment or to create a new one. When a valid subdeployment is selected, its targeted JMS servers, servers, or cluster appear as selected in the Targets box.

Configuring a Connection Factory

In the Administration Console, navigate to the connection factory resource that you want to configure. Click the Configuration tab as shown in the slide. You can configure the properties using the Default Delivery subtab.

•Default Priority: The default priority that is used for messages when a priority is not explicitly defined. Values are between 0 and 9.

•Default Time-to-Live: The maximum length of time, in milliseconds, that a message will exist. This value is used for messages when a priority is not explicitly defined. A value of 0 indicates that the message has an infinite amount of time to live.

•Default Time-to-Deliver: The delay time, in milliseconds, between when a message is produced and when it is made visible on its destination

•Default Delivery Mode: Whether or not messages should use a persistent store, if one is associated with the JMS server

•Default Redelivery Delay: The delay time, in milliseconds, before rolled back or recovered messages are redelivered

•Send Timeout: The maximum length of time, in milliseconds, that a sender will wait when there is not enough space available (no quota) on a destination to accommodate the message being sent. The default time is 10 milliseconds.

Destination

A JMS destination identifies a queue (point-to-point) or topic (Publish/Subscribe) for a JMS server.

After configuring a JMS server, configure one or more queue or topic destinations for each JMS server. You configure destinations explicitly or by configuring a destination template that can be used to define multiple destinations with similar attribute settings.

A JMS destination identifies a queue (point-to-point) or topic (Publish/Subscribe) resource within a JMS module. Each queue and topic resource is targeted to a specific JMS server. A JMS server’s primary responsibility for its targeted destinations is to maintain information about the persistent store that is used for any persistent messages that arrive on the destinations and to maintain the states of the durable subscribers created on the destinations.

Queue Destinations

The point-to-point (PTP) messaging model enables one application to send a message to another. PTP messaging applications send and receive messages using named queues. A queue sender (producer) sends a message to a specific queue. A queue receiver (consumer) receives messages from a specific queue. Multiple queue senders and queue receivers can be associated with a single queue, but an individual message can be delivered to only one queue receiver.

If multiple queue receivers are listening for messages on a queue, WebLogic JMS determines which one will receive the next message on a first come, first serve basis. If no queue receivers are listening on the queue, messages remain in the queue until a queue receiver attaches to the queue.

Topic Destinations

The Publish/Subscribe (pub/sub) messaging model enables an application to send a message to multiple applications. Pub/sub messaging applications send and receive messages by subscribing to a topic. A topic publisher (producer) sends messages to a specific topic. A topic subscriber (consumer) retrieves messages from a specific topic. Unlike the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to receive the same message. JMS retains the message until all topic subscribers have received it.

The pub/sub messaging model supports durable subscribers. For durable subscriptions, WebLogic JMS stores a message in a persistent file or database until the message is delivered to the subscribers or has expired, even if those subscribers are not active at the time the message is delivered. To support durable subscriptions, a client identifier (client ID) must be defined for the connection by the JMS client application. Support for durable subscriptions is a feature that is unique to the pub/sub messaging model, so client IDs are used only with topic connections; queue connections also contain client IDs, but JMS does not use them.

Creating a Destination (Topic)

After you create a JMS system module, you can configure resources for the module, including stand-alone queues and topics, distributed queues and topics, connection factories, JMS templates, destination sort keys, destination quota, foreign servers, and JMS store-and-forward (SAF) parameters.

For each destination, you can optionally select a subdeployment or create a new subdeployment for the resource. A subdeployment is a mechanism by which targetable JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as JMS servers, server instances, or a cluster).

1.  In the Administration Console, expand Services > Messaging and click JMS Modules. Select an existing JMS module.

2.  On the Configuration page, click New above the Summary of Resources table.

3.  Select the type of destination to create: Queue or Topic. Click Next.

4.  Enter Name and JNDI Name for the destination. Click Next.

5.  Select an existing Subdeployment from this JMS module. Your new JMS destination will be targeted to the JMS servers indicated by the subdeployment.

Durable Subscribers and Subscriptions

Nondurable subscriptions last for the lifetime of their subscriber object. That is, a client will see the messages published on a topic only while its subscriber is active. An inactive subscriber does not see messages that are published on its topic.

Support for durable subscriptions is a feature that is unique to the Publish/Subscribe messaging model. Client IDs are used only with topic connections.

An inactive durable subscription is one that exists but does not currently have a message consumer subscribed to it.

How a Durable Subscription Works

A durable subscriber registers a durable subscription with a unique identity that is retained by JMS. Subsequent subscriber objects with the same identity resume the subscription in the state it was left in by the previous subscriber. If there is no active subscriber for a durable subscription, JMS retains the subscriber’s messages until they are received by the subscriber or until they expire.

Sessions with durable subscribers must always provide the same client identifier. Each client must specify a name that uniquely identifies (within the client identifier) each durable subscription that it creates. Only one session at a time can have a TopicSubscriber for a particular durable subscription.

Configuring a Durable Subscription

No two JMS servers can use the same backing store.

File persistence is much faster than JDBC because JDBC persistence relates to reads from and writes to a database that could potentially be a bottleneck for your system. Synchronization occurs one by one. To enhance the speed and efficiency of persisting to a database, you may like to consider the use of Oracle Coherence.

JMS backing stores can increase the amount of memory required during the initialization of an Oracle WebLogic Server as the number of stored messages increases. If initialization fails due to insufficient memory, when you are rebooting an Oracle WebLogic Server, increase the heap size of the Java Virtual Machine (JVM) proportional to the number of messages that are stored in the JMS backing store. Try to reboot again.

Persistent Messaging

A persistent message is guaranteed to be delivered only once. It is not considered sent until it has been safely written to a WebLogic persistent store that is assigned to each JMS server during configuration.

Nonpersistent messages are not stored. If a connection is closed or recovered, all nonpersistent messages that have not yet been acknowledged will be redelivered. After a nonpersistent message is acknowledged, it will not be redelivered.

WebLogic persistent stores provide built-in, high-performance storage solutions for the Oracle WebLogic Server subsystems and services that require persistence. For example, they can store persistent JMS messages or temporarily store messages that are sent using the JMS store-and-forward feature. The persistent store supports persistence to a file-based store or to a JDBC-enabled database. Each server instance, including the administration server, has a default persistent store that requires no configuration. The default store is a file-based store that maintains its data in a group of files in the data\store\default directory of a server instance.

Configure persistent messaging if:

•Development requires durable subscriptions (use durable subscribers in the application)

•You require that in-progress messages persist across server restarts

Creating a JMS Store

There is a default store for every WebLogic Server instance. The default store can be configured, but cannot point to a database. You may need to create a custom store to point to a database. Similarly, you may want to create a custom file store on your choice of storage device that can enable you to migrate the store to another server member in a cluster. When configuring a file store directory, the directory must be accessible to the server instance on which the file store is located.

1.  In the left pane of the console, expand Services and select Persistent Stores.

2.  On the Summary of Persistent Stores page, select the store type from the New list.

3.  If File Store is selected, update the following on the Create a new File Store page:

-Name: Name of the store

-Target: Server instance on which to deploy the store

-Directory: Path name to the directory on the file system where the file store is placed. This directory must exist on your system, so be sure to create it before completing this tab.

Creating a JDBC Store for JMS

When using JMS JDBC Store, use a separate schema.

The JDBC Store Configuration page provides an optional “Create Table from DDL File” option with which you can access a preconfigured DDL file that is used to create the JDBC Store’s backing table (WLStore). This option is ignored when the JDBC Store’s backing table exists. It is mainly used to specify a custom DDL file created for an unsupported database or when upgrading the JMS JDBC Store tables from a prior release to a current JDBC Store table.

If a DDL file name is not specified in the “Create Table from DDL File” field, and the JDBC Store detects that its backing table does not exist, the JDBC Store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor.

If a DDL file name is specified in the “Create Table from DDL File” field and the JDBC Store detects that its backing table does not already exist, the JDBC Store searches for the specified DDL file in the file path first, and then, if not found, searches for the DDL file in the CLASSPATH. After it is found, the SQL within the DDL file is executed to create the JDBC Store’s backing table. If the configured file is not found and the table does not already exist, the JDBC Store fails to boot.

Creating a JMS JDBC Store

Prefix Name: The prefix for table names, if:

•The database management system requires fully qualified names, such as schema

•You must differentiate between the JMS tables for two Oracle WebLogic Servers to store multiple tables on one DBMS

Assigning a Store to a JMS Server

Associate your new custom persistent store with a JMS server by using the Persistent Store field of the Configuration > General tab. If this field is set to “(none),” the JMS server uses the default file store that is automatically configured on each targeted server instance.

Persistent Connection Factory

Default Delivery Mode: Used for messages for which a delivery mode is not explicitly defined. It can be persistent or nonpersistent.

The preferred method, according to the JMS specification, is to configure the connection factory with the client ID. For Oracle WebLogic Server JMS, this means adding a separate connection factory definition during configuration for each client ID. Applications look up their own topic connection factories in JNDI and use them to create connections containing their own client IDs.

Alternatively, an application can set its client ID programmatically.

Viewing Active Queues and Topics

You can use this page to monitor information about a JMS consumer, which receives messages from a JMS queue (QueueReceiver) or topic (TopicSubscriber).

You can show fewer or additional data points on this page by expanding “Customize this table” and modifying the Column Display list. Each data point displays in its own table column.

 

Managing Messages in a Queue

You can enable viewing of messages in the Administration Console using these steps:

1.  In the Administration Console, navigate to the queue resource that you want to configure:

-Navigate to JMS Resources in System Modules, and then to JMS resources in an application module

2.  Click the Monitoring tab.

3.  Select the check box next to the queue, and then click Show Messages to access the queue’s JMS Messages table.

4.  You can then perform the following administrative procedures on a specific message or selected messages:

-Click a message in the queue to open the View Contents page, where you can view the contents of a JMS message.

-Click New to create a new JMS message. You can specify header and body content when creating the message, which will then be produced on the current queue.

-Select messages for deletion and click Delete to delete them from the current queue.

-Click Move to transfer selected JMS messages from the current queue to another destination, including a destination on a different JMS server.