bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search
e-docs > WebLogic Server > Administration Console Online Help > JMS: Configuring

Administration Console Online Help

 Previous Next Contents Index  

JMS: Configuring

 

JMS and WebLogic Server

JMS (Java Message Service) is a standard API for accessing enterprise messaging systems. Specifically, WebLogic JMS:

The following figure illustrates WebLogic JMS messaging.

Figure 1-1 WebLogic Server JMS Messaging


 

As illustrated in the figure, WebLogic JMS accepts messages from producer applications and delivers them to consumer applications.

 

Configuring JMS

Using the Administration Console, you define configuration attributes to:

WebLogic JMS provides default values for some configuration attributes; you must provide values for all others. If you specify an invalid value for any configuration attribute, or if you fail to specify a value for an attribute for which a default does not exist, WebLogic Server will not boot JMS when you restart it.

A sample examplesJMSServer configuration is provided with the product in the Examples Server. For more information about starting the Examples Server, see "Starting the Default, Examples, and Pet Store Servers" in the Installation Guide.

When you port WebLogic JMS applications from a previous release of Weblogic Server, the configuration information is automatically converted, as described in "Porting WebLogic JMS Applications" in Programming WebLogic JMS.

Once WebLogic JMS is configured, applications can send and receive messages using the JMS API. For more information about developing WebLogic JMS applications, refer to "Developing a WebLogic JMS Application" in Programming WebLogic JMS.

Note: To assist with your WebLogic JMS configuration planning, Programming WebLogic JMS provides configuration checklists for the attribute requirements and/or options that support various JMS features.

 

JMS Server Tasks

A JMS server manages connections and message requests on behalf of clients. Use the Services —> JMS —> Server node to configure a JMS server and assign it to either an independent WebLogic Server instance or a migratable server target where it will be deployed.

Configuring a JMS Server

You must first configure a JMS server before you can configure any destinations or consumers.

  1. Expand the JMS —> Servers node. The JMS Servers table displays in the right pane showing all the JMS servers defined in your domain.
  2. Click the Configure a new JMS Server text link. A dialog displays in the right pane showing the tabs associated with configuring a new JMS server.
  3. On the Configuration General tab, define the general configuration attributes for a JMS server:

    For more information about JMS server general attributes, see JMS Server --> Configuration --> General.

  4. Click Create to create a JMS server instance with the name you specified in the Name field. The new instance is added under the JMS Servers node in the left pane. A Destinations node and a Session Pools node are automatically added under the new server instance by default.
  5. On the Configuration Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for a JMS server:

    For more information about the Thresholds & Quota attributes, see JMS Server --> Configuration --> Thresholds & Quotas.

  6. Click Apply to save your changes.
  7. On the Target and Deploy tab, select an independent WebLogic Server or a migratable server target on which to deploy the JMS server.

    For more information see, Targeting and Deploying a JMS Server.

  8. Click Apply to target the JMS server.

Targeting and Deploying a JMS Server

You can assign a JMS server to either an independent WebLogic Server instance or to a migratable target server where it will be deployed. Whereas, a connection factory or template can be instantiated on multiple WebLogic Server instances simultaneously

  1. Under the JMS —> Servers node in the left pane, click the node for the JMS server instance that you want to assign. A dialog displays in the right pane showing the tabs associated with this instance.
  2. Click the Target and Deploy tab.
  3. Complete one of the following steps for targeting either an independent server or a migratable target server:
  4. Click Apply to save your assignments.

Monitoring a JMS Server

On the JMS Monitoring tab, you can monitor statistics for view run-time information for active JMS servers, destinations, and server session pools.

  1. Expand the JMS node.
  2. Click the Servers node. The JMS Servers information displays in the right pane showing all the JMS servers defined in your domain.
  3. Click the JMS server that you want to monitor from the JMS server list, or from the JMS Servers table displayed in the right pane.
  4. Click the Monitoring tab to display the monitoring links for monitoring JMS server data:

For more information about monitoring JMS objects, see JMS: Monitoring.

 

JMS Connection Factory Tasks

Connection factories are objects that enable JMS clients to create JMS connections. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously. You define and configure one or more connection factories to create connections with predefined attributes. WebLogic Server adds them to the JNDI space during startup, and the application then retrieves a connection factory using WebLogic JNDI.

You can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and targeting them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers. For more information on configuring JMS clustering, see "Managing JMS" in Programming WebLogic JMS.

WebLogic JMS defines one connection factory, by default: weblogic.jms.ConnectionFactory. All configuration attributes are set to their default values for this default connection factory. If the default connection factory definition is appropriate for your application, you do not need to configure any additional connection factories for your application.

Note: Using the default connection factory, you have no control over the JMS server on which the connection factory may be deployed. If you would like to target a particular JMS server, create a new connection factory and specify the appropriate JMS server target(s).

Some connection factory attributes are dynamically configurable. When dynamic attributes are modified at run time, the new values become effective for new connections only, and do not affect the behavior of existing connections.

Configuring a JMS Connection Factory

Using the Services —> JMS —> Connection Factories node, you can configure one or more connection factories to create connections with predefined attributes.

  1. Expand the JMS —> Connection Factories node. The JMS Connection Factories table displays in the right pane showing all the connection factories defined in your domain.
  2. Click the Configure a new JMS Connection Factory text link. A dialog displays in the right pane showing the tabs associated with configuring a new connection factory.
  3. On the Configuration General tab, define the general configuration attributes for the connection factory.

    For more information about general connection factory attributes, see JMS Connection Factory --> Configuration --> General.

  4. Click Create to create a connection factory instance with the name you specified in the Name field. The new instance is added under the JMS Connection Factories node in the left pane.
  5. On the Configuration Transactions tab, define a value for the transaction time-out attribute and use the XAConnectionFactoryEnabled field to indicate whether a transaction queue or topic connection factory is returned and whether the connection factory creates sessions that are JTA aware.

    For more information about connection factory transaction attributes, see JMS Connection Factory --> Configuration --> Transactions.

  6. Click Apply to save your changes.
  7. On the Configuration Flow Control tab, define values that instruct a message producer to adjust its message flow. Specifically, the producer receives attributes that limit its flow within a minimum and maximum range. As conditions worsen, the producer moves toward the minimum; as conditions improve; the producer moves toward the maximum. Use the Send Timeout attribute to specify the maximum time that a producers will wait for sufficient quota on a JMS server and destination to accommodate the message that it is attempting to send.

    For more information about connection factory flow control attributes, see JMS Connection Factory --> Configuration --> Flow Control.

  8. Click Apply to save your changes.
  9. On the Target and Deploy tab, assign the connection factory to a WebLogic Server instance or to a server cluster. Targets enable you to limit the set of servers, groups, and/or clusters on which a connection factory may be deployed.

    For more information see, Deploying a Connection Factory on Multiple Individual Servers and Deploying a Connection Factory on a Cluster.

  10. Click Apply to save your changes.

Deploying a Connection Factory on Multiple Individual Servers

You can establish cluster-wide, transparent access to JMS destinations from any server in a domain by deploying connection factories on multiple WebLogic Server instances simultaneously.

  1. Expand the JMS —> Connection Factories node, and then select the connection factory that you want to deploy. A dialog displays in the right pane showing the tabs associated with this instance.
  2. Click the Target and Deploy tab. All the WebLogic Server instances in the domain are listed in the Independent Servers box. A check mark is displayed next to each server already targeted to the connection factory.
  3. To deploy the connection factory on one or more servers in the list, select the check mark displayed next to each server name.
  4. Connection Factories can also be undeployed from individual servers whenever necessary by clearing the check mark displayed next to each server name.
  5. Click Apply to save your assignments.

Deploying a Connection Factory on a Cluster

In a clustered environment, you can establish cluster-wide, transparent access to JMS destinations from any server in a cluster by deploying connection factories on all the servers in a cluster or to selected servers within a cluster.

  1. Expand the JMS —> Connection Factories node, and then select the connection factory that you want to deploy. A dialog displays in the right pane showing the tabs associated with this instance.
  2. Click the Target and Deploy tab. All the clusters configured in the domain are listed in the Clusters box. A check mark is displayed next to each cluster name already targeted to the connection factory.
  3. The Connection factory can be targeted to either all the servers in a cluster or to selected servers within a cluster:
  4. Connection Factories can also be undeployed from an entire cluster or from selected servers within a cluster whenever necessary, by doing the following:
  5. Click Apply to save your assignments.

 

JMS Destination Tasks

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, as described in JMS Template Tasks.

Note: You can also configure multiple physical destinations as members of a single distributed destination set within a cluster. Therefore, if one instance within the cluster fails, then other instances of the same destination will be able to provide service to JMS producers and consumers. For more information, see JMS Distributed Destination Tasks.

Some destination attributes are dynamically configurable. When attributes are modified at run time, only incoming messages are affected; stored messages are not affected.

Creating a JMS Queue

A JMS queue defines a point-to-point destination type for a JMS server. After defining a JMS server, configure one or more queue destinations for each JMS server.

  1. Expand the JMS —> Servers node and select a JMS server instance.
  2. Click the Destinations node. The JMS Destinations table displays in the right pane showing all the JMS queues.
  3. Click the Configure a new JMS Queue text link. A dialog shows the tabs associated with configuring a new queue.
  4. On the Configuration General tab, define the general configuration attributes for the queue.

    For more information about the queue general attributes, see JMS Queue --> Configuration --> General.

  5. Click Create to create a queue instance with the name you specified in the Name field. The new instance is added under the Destinations node in the left pane.
  6. On the Configuration Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for the queue:

    For more information about the Thresholds & Quota attributes, see JMS Queue --> Configuration --> Thresholds & Quotas.

  7. On the Configuration Overrides tab, define the message attributes that can override those specified by a message producer, including the priority, time-to-live, time-to-deliver, and delivery mode.

    For more information about the queue override attributes, see JMS Queue --> Configuration --> Overrides.

  8. On the Configuration Redelivery tab, define the message redelivery attributes, including redelivery delay override, redelivery limit, and error destination.

    For more information about the queue redelivery attributes, see JMS Queue --> Configuration --> Redelivery.

  9. On the Configuration Expiration Policy tab, define the message expiration policy to use when expired messages are encountered on the queue.

    For more information about the queue expiration policy attributes, see JMS Queue --> Configuration --> Expiration Policy.

  10. Click Apply to save any changes you made on these tabs.

Creating a JMS Topic

A JMS topic identifies a publish/subscribe destination type for a JMS server. After defining a JMS server, configure one or more topic destinations for each JMS server.

  1. Expand the JMS —> Servers node and select a JMS server instance.
  2. Click the Destinations node. The JMS Destinations table displays in the right pane showing any configured JMS topics.
  3. Click the Configure a new JMS Topic text link. A dialog shows the tabs associated with configuring a new topic.
  4. On the Configuration General tab, define the general configuration attributes for the topic.

    For more information about the topic general attributes, see JMS Topic --> Configuration --> General.

  5. Click Create to create a topic instance with the name you specified in the Name field. The new instance is added under the Destinations node in the left pane.
  6. On the Configuration Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for the topic:

    For more information about the topic Thresholds & Quota attributes, see JMS Topic --> Configuration --> Thresholds & Quotas.

  7. On the Configuration Overrides tab, define the message attributes that can override those specified by a message producer, including the priority, time-to-live, time-to-deliver, and delivery mode.

    For more information about the topic override attributes, see JMS Topic --> Configuration --> Overrides.

  8. On the Configuration Redelivery tab, define the message redelivery attributes, including redelivery delay override, redelivery limit, and error destination.

    For more information about the topic redelivery attributes, see JMS Topic --> Configuration --> Redelivery.

  9. On the Configuration Expiration Policy tab, define the message expiration policy logging properties to use when expired messages are encountered on the topic.

    For more information about the topic expiration policy attributes, see JMS Topic --> Configuration --> Expiration Policy.

  10. On the Configuration Mulitcast tab, define the mulitcast attributes for the topic, including a multicast address, time-to-live (TTL), and port.

    For more information about the topic expiration policy attributes, see JMS Topic --> Configuration --> Multicast.

  11. Click Apply to save any changes you made on these tabs.

 

JMS Template Tasks

A JMS template provides an efficient means of defining multiple destinations with similar attribute settings. JMS templates offer the following benefits:

The configurable attributes for a JMS template are the same as those configured for a destination. These configuration attributes are inherited by the destinations that use them, with the following exceptions:

Any attributes that are not explicitly defined for a destination are assigned default values. If no default value exists, be sure to specify a value within the JMS template or as a destination attribute override. If you do not do so, the configuration information remains incomplete, the WebLogic JMS configuration fails, and the WebLogic JMS does not boot.

Creating a JMS Template

To define the JMS template configuration attributes for destinations, use the JMS —> Templates node.

  1. Expand the JMS —> Templates node. The JMS Templates table displays in the right pane showing all the templates defined in the domain.
  2. Click the Configure a new JMS Template text link. A dialog displays in the right pane showing the tabs associated with configuring a new template.
  3. On the Configuration General tab, define the general configuration attributes for the JMS template.

    For more information about the topic general attributes, see JMS Template --> Configuration --> General.

  4. Click Create to create a template instance with the name you specified in the Name field. The new instance is added under the Templates node in the left pane.
  5. On the Configuration Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for the destinations created from this JMS template:

    For more information about the JMS template Thresholds & Quota attributes, see JMS Template --> Configuration --> Thresholds & Quotas.

  6. On the Configuration Override tab, define the message attributes that can override those specified by a message producer for destinations created from this JMS template, including the priority, time-to-live, time-to-deliver, and delivery mode.

    For more information about the JMS template override attributes, see JMS Template --> Configuration --> Override.

  7. On the Configuration Redelivery tab, define the message redelivery attributes for destinations created from this JMS template, including redelivery delay override, redelivery limit, and error destination.

    For more information about the JMS template redelivery attributes, see JMS Topic --> Configuration --> Redelivery.

  8. On the Configuration Expiration Policy tab, define the message expiration policy logging properties to use when expired messages are encountered on destinations created from this JMS template.

    For more information about the JMS template expiration policy attributes, see JMS Template --> Configuration --> Expiration Policy.

  9. Click Apply to save any changes you made on these tabs.

 

Destination Keys Tasks

Use destination keys to define the sort order for messages that arrive on a specific destination.

Creating a JMS Destination Key

To create a destination key, use the Destination Keys node.

  1. Expand the JMS —> Destination Keys node. The JMS Destinations Keys table displays in the right pane showing all the destination keys.
  2. Click the Create a new JMS Destination Key text link. A dialog shows the tabs associated with configuring a new destination key.
  3. On the Configuration General tab, define the general destination key attributes:

    For more information about the JMS destination key attributes, see JMS Destination Key --> Configuration.

  4. Click Create to create a destination key instance with the name you specified in the Name field. The new instance is added under the Destination Keys node in the left pane.

 

JMS File Store Tasks

WebLogic JMS can store persistent messages in either a JDBC-accessible database or a disk-based file. The following are some similarities and differences between file stores and JDBC stores.

JMS stores can increase the amount of memory required during initialization of a WebLogic Server instance as the number of stored messages increases. If initialization fails due to insufficient memory while rebooting WebLogic Server, increase the heap size of the Java Virtual Machine (JVM) proportionally to the number of messages that are currently stored in the JMS store. Then, try rebooting the server again. For more information on setting heap sizes, see "Tuning WebLogic Server Applications" in the WebLogic Performance and Tuning Guide.

Creating a JMS File Store

A disk-based JMS file store stores persistent messages and durable subscribers in a file-system directory. This directory must exist on your system, so be sure to create it before completing this tab.

  1. Expand the JMS —> Stores node. The JMS Stores table displays in the right pane showing all the JMS stores.
  2. Click the Create a new JMS File Store text link. A dialog shows the tabs associated with configuring a new file store.
  3. On the Configuration tab, define the general file store attributes:

    For more information about the JMS file store attributes, see JMS File Store --> Configuration.

  4. Click Create to create a file store instance with the name you specified in the Name field. The new instance is added under the Stores node in the left pane.

Configuring a Paging Store

A JMS file store is the recommended store type when configuring message paging for the JMS server and destinations. A paging store cannot be the same JMS file store used for storing persistent messages or durable subscribers for a JMS server. Therefore, you need to configure an additional JMS file store to be used exclusively for message paging for each JMS server.

  1. Expand the JMS —> Stores node. The JMS Stores table displays in the right pane showing all the JMS stores.
  2. Click the Create a new JMS File Store text link. A dialog shows the tabs associated with configuring a new file store.
  3. On the Configuration tab, define the general file store attributes:

    For more information about the JMS file store attributes, see JMS File Store --> Configuration.

  4. Click Create to create a paging store instance with the name you specified in the Name field. The new instance is added under the Stores node in the left pane.
  5. Make sure to select this "paging" file store on the JMS Server Configuration General tab.

For more information on configuring paging, see Paging Out Messages To Free Up Memory.

 

JMS JDBC Store Tasks

Through the use of JDBC, JMS enables you to store persistent messages in a database, which is accessed through a designated JDBC connection pool. The JMS database can be any database that is accessible through a JDBC driver. WebLogic JMS detects some drivers for the following databases:

The weblogic/jms/ddl directory within the weblogic.jar file contains JMS DDL files for these databases, which are actually text files containing the SQL commands that create the JMS database tables. To use a different database, simply copy and edit any one of these .ddl files.

Note: The JMS samples provided with your WebLogic Server distribution are set up to work with the Pointbase Java database. An evaluation version of Pointbase is included with WebLogic Server and a demoPool database is provided.

If your existing JMS JDBC stores somehow become corrupted, you can regenerate them using the utils.Schema utility. For more information see, "JDBC Database Utility" in Programming WebLogic JMS.

Creating a JMS JDBC Store

  1. Expand the JMS —> Stores node. The JMS Stores table displays in the right pane showing all the JMS stores.
  2. Click the Create a new JMS JDBC Store text link. A dialog shows the tabs associated with configuring a new JDBC store.
  3. On the Configuration tab, define the general JMS JDBC store attributes:

    For more information about the JMS JDBC store attributes, see JMS JDBC Store --> Configuration.

  4. Click Create to create a JDBC store instance with the name you specified in the Name field. The new instance is added under the Stores node in the left pane.

Using Prefixes with JMS JDBC Stores

The JMS database contains two system tables that are generated automatically and are used internally by JMS:

When a JMS JDBC store is used, WebLogic Server JMS may spend a significant amount of time scanning all database tables to find its own tables. If, however, the name of the store includes a unique prefix that includes the schema name, this search time can be reduced, thus improving boot performance.

For this reason we recommend adding a unique prefix to the store name when configuring a JMS JDBC store to identify JMS tables in the store. The prefix may be any string, but in many databases, the user name is used as the schema name. A prefix is prepended to table names when the DBMS requires fully qualified names, or when you must differentiate between JMS tables for two WebLogic Servers, enabling multiple tables to be stored on a single DBMS.

Warning: No two JMS stores should be allowed to use the same database tables, as this will result in data corruption.

Specify the prefix using the following format, which will result in a valid table name when prepended to the JMS table name:

[[[catalog.]schema.]prefix]JMSStore

where catalog identifies the set of system tables being referenced by the DBMS and schema translates to the ID of the table owner. For example, in a production database the JMS administrator could maintain a unique table for the Sales department, as follows:

[[[Production.]JMSAdmin.]Sales]JMSStore

Note: For some DBMS vendors, such as Oracle, there is no catalog to set or choose, so this format simplifies to [[schema.]prefix]. For more information, refer to your DBMS documentation for instructions on how to write and use a fully-qualified table name.

Recommended JDBC Connection Pool Settings for JMS JDBC Stores

WebLogic Server provides robust JDBC connection pools that can automatically reconnect to failed databases after they come back online, without requiring you to restart WebLogic Server. To take advantage of this capability, and make your use of JMS JDBC stores more robust, configure the following attributes on the JDBC connection pool associated with the JMS JDBC store:

TestConnectionsOnReserve="true"
TestTableName="[[[catalog.]schema.]prefix]JMSState"

Handling Transactions with JMS JDBC Stores

You cannot configure a transaction (XA) JDBC connection pool or JDBC TxDataSource to use with a JMS JDBC store. JMS must use a JDBC connection pool that uses a non-TxDataSource with a non-XAResource driver (you cannot use an XA driver or a JTS driver, or implement the "Emulate Two-Phase Commit for non-XA Driver" option). WebLogic JMS does the XA support above the JDBC driver.

This is because WebLogic JMS is its own resource manager. That is, JMS itself implements the XAResource and handles the transactions without depending on the database (even when the messages are stored in the database). This means that whenever you are using JMS and a database (even if it is the same database where the JMS messages are stored), then it is two-phase commit transaction. For more information about using transactions with WebLogic JMS, see "Using Transactions with WebLogic JMS" in Programming WebLogic JMS.

From a performance perspective, you may boost your performance if the JDBC connection pool used for the database work exists on the same WebLogic Server as the JMS queue—the transaction will still be two-phase, but it will be handled with less network overhead. Another performance boost might be achieved by using JMS file stores rather than JMS JDBC stores.

 

Session Pools Tasks

Server session pools enable an application to process messages concurrently. After you define a JMS server, optionally, configure one or more session pools for each JMS server. Some session pool attributes are dynamically configurable, but the new values do not take effect until the session pools are restarted.

For more information about creating session pools, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS

Creating a JMS Session Pool

Use the Session Pools node in the Administration Console and define the following configuration attributes:

  1. Expand the JMS —> Servers node.
  2. Expand a JMS server instance under Servers.
  3. Click the Session Pools node. The Session Pools table displays in the right pane showing all the session pools.
  4. Click the Configure a new JMS Session Pool text link. A dialog shows the tabs associated with configuring a new session pool.
  5. On the Configuration tab, define the general session pool attributes:

    For more information about the session pool attributes, see JMS Session Pool --> Configuration.

  6. Click Create to create a session pool instance with the name you specified in the Name field. The new instance is added under the Session Pools node in the left pane.

 

Connection Consumers Tasks

Connection consumers are queues (Point-To-Point) or topics (Pub/Sub) that retrieve server sessions and process messages. After you define a session pool, configure one or more connection consumers for each session pool.

For more information about creating connection consumers, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS

Creating a JMS Connection Consumer

To configure connection consumers, use the Session Pools node to define the following configuration attributes:

  1. Expand the JMS —> Servers node.
  2. Expand a JMS server instance under Servers.
  3. Expand the Session Pools node, and then click a session pool instance.
  4. Click the Consumers node. The JMS Consumers table displays in the right pane showing all the connection consumers.
  5. Click the Configure a new JMS Connection Consumer text link. A dialog shows the tabs associated with configuring a new connection consumer.
  6. On the Configuration tab, define the general connection consumer attributes:

    For more information about the connection consumer attributes, see JMS Connection Consumer --> Configuration.

  7. Click Create to create a connection consumer instance with the name you specified in the Name field. The new instance is added under the Consumers node in the left pane.

 

JMS Distributed Destination Tasks

To provide service continuity in the event of a WebLogic Server instance failure within a cluster, you can configure multiple physical JMS destinations (queues and topics) as members of a single distributed destination set that can be served by multiple WebLogic Server instances within a cluster. Once properly configured, your producers and consumers are able to send messages to and receive messages from the distributed destination. WebLogic JMS then distributes the messaging load across all available physical destination members within the distributed destination. In the event that a member becomes unavailable due to a server failure in the cluster, traffic is then redirected toward the other available destination members in the set.

For more information about creating distributed destinations, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS.

Guidelines for Configuring Distributed Destinations

You configure distributed JMS destinations through the Services —> JMS —> Distributed Destinations node. To facilitate the configuration process, these instructions are divided into procedures that address the following scenarios:

Note: The default Load Balancing Enabled and Server Affinity Enabled attributes for tuning a distributed destination configuration can be modified on the JMS connection factory through the Administration Console. For more information, see Configuring Message Load Balancing on Distributed Destinations and Configuring Server Affinity for Distributed Destinations.

Creating a Distributed Topic and Creating Members Automatically

Follow these steps to configure a distributed topic and automatically create its topic members on JMS servers that are part of a WebLogic Server cluster (for high availability) or on an single WebLogic Server instance that is not part of a cluster.

  1. Expand the JMS —> Distributed Destinations node.
  2. Click the Configure a new Distributed Topic link in the right pane. A dialog shows the tabs associated with configuring a new distributed topic.
  3. On the Configuration General tab, define the general configuration attributes for the distributed topic.

    For more information about the distributed topic general attributes, see JMS Distributed Topic --> Configuration --> General.

  4. Click Create to create a distributed topic instance with the name you specified in the Name field. The new instance is added under the Distributed Destinations node in the left pane.
  5. On the Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for all distributed topic members:

    For more information about these attributes, see JMS Distributed Topic --> Configuration --> Thresholds and Quotas.

  6. Click Apply to save any changes you made on this tab.
  7. On the Auto Deploy tab, indicate the WebLogic Server instances where you want the distributed topic members to be automatically created.
  8. Click the Create members on the selected Servers (and JMS Servers) text link. An auto deploy dialog prompts you to select one of the following options:
  9. If you selected a cluster, do the following to select WebLogic Server instances within the cluster:
    1. All WebLogic Server instances that are members of the cluster and that are not already hosting a distributed topic are listed and are selected by default. To exclude a server instance from hosting the distributed topic, clear the corresponding check box.
    2. Click Next to proceed to the next dialog.
    3. Skip to Step 11 to select the JMS servers that are available on the selected WebLogic Servers for creating distributed topic members.
  10. If you selected None on the Cluster dialog in Step 8, select a single WebLogic Server instance in the domain:
    1. From the list box, select an individual server where you want to create a distributed topic member.
    2. Click Next to proceed to the next dialog.
  11. All JMS servers that are deployed on the selected WebLogic Server instances, and that are not already hosting a distributed topic, are listed and are selected by default. To exclude a JMS server from hosting the distributed topic member, clear the corresponding check box.

    If there are no existing distributed topic members on the selected JMS servers, one new JMSTopic will be created on each JMS server and added as a member of the distributed topic.

  12. Click Next to proceed to the final Auto Deploy dialog.
  13. Click Apply to save your Auto Deploy selections.
  14. Click the Configuration —> Members tab to view the topic members that were automatically created for the new distributed topic.

Creating a Distributed Topic and Adding Existing Physical Topics as Members Manually

For existing implementations of WebLogic JMS that require previously configured destinations to be members of a distributed destination set, follow these steps to configure a distributed topic and manually add your existing physical topics as members:

  1. Expand the JMS —> Distributed Destinations node.
  2. Click the Configure a new Distributed Topic link in the right pane. A dialog shows the tabs associated with configuring a new distributed topic.
  3. On the Configuration General tab, define the general configuration attributes for the distributed topic.

    For more information about the distributed topic general attributes, see JMS Distributed Topic --> Configuration --> General.

  4. Click Create to create a distributed topic instance with the name you specified in the Name field. The new instance is added under the Distributed Destinations node in the left pane.
  5. On the Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quota attributes for all distributed topic members:

    If a distributed topic member's underlying physical topic already uses a JMS Template with configured thresholds and quotas, these attributes will not apply to that topic member. For more information about these attributes, see JMS Distributed Topic --> Configuration --> Thresholds and Quotas.

  6. Click Apply to Apply to save any changes you made on this tab.

    Note: If you want to automatically create topic members on JMS servers that are part of a WebLogic Server cluster (for high availability) or on an single WebLogic Server instance that is not part of a cluster, see Creating a Distributed Topic and Creating Members Automatically.

  7. On the Configuration —> Members tab, create distributed topic members for your existing physical topics.
  8. Click the Configure a new Distributed Topic Member link in the right pane. A Configuration dialog shows the tabs associated with configuring a new distributed topic member.
  9. On the Configuration tab, define the general configuration attributes for the distributed topic.

    For more information about distributed topic member attributes, see JMS Distributed Topic Member --> Configuration.

  10. Click Create to create the new distributed topic member. The new member is added to the Distributed Topic table.
  11. If necessary, repeat steps 8-10 to continue adding topic members to the distributed topic.

Creating a Distributed Queue and Creating Members Automatically

Follow these steps to configure a distributed queue and automatically create its queue members on JMS servers that are part of a WebLogic Server cluster (for high availability) or on an single WebLogic Server instance that is not part of a cluster.

  1. Expand the JMS —> Distributed Destinations node.
  2. Click the Configure a new Distributed Queue link in the right pane. A Configuration dialog shows the tabs associated with configuring a new distributed queue.
  3. On the Configuration General tab, define the general configuration attributes for the distributed topic.

    For more information about the distributed queue general attributes, see JMS Distributed Queue --> Configuration --> General.

  4. Click Create to create a distributed queue instance with the name you specified in the Name field. The new instance is added under the Distributed Destinations node in the left pane.
  5. On the Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quotas for all distributed queue members:

    If a distributed queue member's underlying physical queue already uses a JMS Template with configured thresholds and quotas, these attributes will not apply to that queue member. For more information about these attributes, see JMS Distributed Topic --> Configuration --> Thresholds and Quotas.

  6. Click Apply to save any changes you made on this tab.
  7. On the Auto Deploy tab, indicate the WebLogic Server instances where you want the distributed queue members to be automatically created.
  8. Click the Create members on the selected Servers (and JMS Servers) text link. A dialog prompts you to select one of the following options:
  9. If you selected a cluster, do the following to select WebLogic Server instances within the cluster:
    1. All servers that are members of the cluster, and which are not already hosting a distributed queue, are listed and are selected by default. To exclude a server from hosting the distributed queue, clear the corresponding check box.
    2. Click Next to proceed to the next dialog.
    3. Skip to Step 11 to select the JMS servers that are available on the selected WebLogic Servers for creating distributed queue members.
  10. If you selected None on the Cluster dialog in Step 8, select a single WebLogic Server instance in the domain:
    1. From the list box, select an individual server where you want to create the distributed queue member.
    2. Click Next to proceed to the next dialog.
  11. All JMS servers that are deployed on the selected WebLogic Servers, and which are not already hosting a distributed queue, are listed and are selected by default. To exclude a JMS server from hosting the distributed queue member, clear the corresponding check box.

    If there are no existing distributed queue members on the selected JMS servers, one new JMSQueue will be created on each JMS server and added as a member of the distributed queue.

  12. Click Next to proceed to the final Auto Deploy dialog.
  13. Click Apply to save your Auto Deploy selections.
  14. Click the Configuration —> Members tab to view the queue members that were automatically created for the new distributed queue.

Creating a Distributed Queue and Adding Existing Physical Queues as Members Manually

For existing implementations of WebLogic JMS that require previously configured destinations to be members of a distributed destination set, follow these steps to configure a distributed queue and manually add your existing physical queues as members.

  1. Expand the JMS —> Distributed Destinations node.
  2. Click the Configure a new Distributed Queue link in the right pane. A Configuration dialog shows the tabs associated with configuring a new distributed queue.
  3. On the Configuration General tab, define the general configuration attributes for the distributed topic.

    For more information about the distributed queue general attributes, see JMS Distributed Queue --> Configuration --> General.

  4. Click Create to create a distributed queue instance with the name you specified in the Name field. The new instance is added under the Distributed Destinations node in the left pane.
  5. On the Thresholds & Quotas tab, define the following upper and lower message/byte threshold and maximum quotas for all distributed queue members:

    If a distributed queue member's underlying physical queue already has a JMS Template with configured thresholds and quotas, these attributes will not apply to that queue member. For more information about these attributes, see JMS Distributed Queue --> Configuration --> Thresholds and Quotas.

  6. Click Apply to save any changes you made on this tab.

    Note: If you want to automatically create queue members on JMS servers that are part of a WebLogic Server cluster (for high availability) or on an single WebLogic Server instance that is not part of a cluster, see Creating a Distributed Queue and Creating Members Automatically.

  7. Click the Configuration —> Members tab to define the queue members for the distributed queue.
  8. Click the Configure a new Distributed Queue Member text link in the right pane. A Configuration dialog shows the tabs associated with configuring a new distributed queue member.
  9. On the Configuration tab, define the general configuration attributes for the distributed queue.

    For more information about distributed queue member attributes, see JMS Distributed Queue Member --> Configuration.

  10. Click Create to create the new distributed queue member. The new member is added to the Distributed Queue table.
  11. Repeat steps 8-10 to continue adding members to the distributed queue.

Creating a JMS Distributed Queue Member

Follow these steps to add an existing physical queue as a member of distributed queue set.

  1. Expand the JMS —> Distributed Destinations node. The Distributed Destinations table displays in the right pane showing all the distributed queues and topics.
  2. Click the distributed queue that you want to add a member to. The Distributed Queue table shows all the distributed queue members that belong to the distributed queue.
  3. Click the Configure a new Distributed Queue Member text link. A dialog shows the Configuration tab for configuring a new distributed queue member.
  4. Define the configuration attributes for the distributed queue.

    For more information about distributed queue member attributes, see JMS Distributed Queue Member --> Configuration.

  5. Click Create to create a distributed queue member with the name you specified in the Name field. The new member is added to the Distributed Queue Member table in the right pane.
  6. Click Apply to save any changes you made.

Deleting a JMS Distributed Queue Member

Follow these steps to delete a member of distributed queue set, and if necessary, to delete the member's underlying physical queue.

  1. Expand the JMS —> Distributed Destinations node. The Distributed Destinations table displays in the right pane showing all the distributed queues and topics.
  2. Click the distributed queue that you want to delete a member from. The Distributed Queue table shows all the distributed queue members that belong to the distributed queue.
  3. Click the Delete icon in the row of the distributed queue member that you want to delete. A dialog prompts you to confirm your deletion request.
  4. If you want to also remove the underlying physical queue, select the Also Delete check box.
  5. Click Remove to delete the distributed queue member (and the underlying physical queue if selected).
  6. The Distributed Queue table redisplays in the right pane. The distributed queue member is deleted from the Distributed Queue table.

Creating a JMS Distributed Topic Member

Follow these steps to add an existing physical queue as a member of distributed queue set.

  1. Expand the JMS —> Distributed Destinations node. The Distributed Destinations table displays in the right pane showing all the distributed queues and topics.
  2. Click the distributed topic that you want to add a member to. The Distributed Topic table shows all the distributed topic members that belong to the distributed topic.
  3. Click the Configure a new Distributed Topic Member text link. A dialog shows the Configuration tab for configuring a new distributed topic member.
  4. Define the general configuration attributes for the distributed topic.

    For more information about distributed topic member attributes, see JMS Distributed Topic Member --> Configuration.

  5. Click Create to create a distributed topic member with the name you specified in the Name field. The new member is added to the Distributed Topic table in the right pane.
  6. Click Apply to save any changes you made.

Deleting a JMS Distributed Topic Member

Follow these steps to delete a member of distributed topic set, and if necessary, to delete the member's underlying physical topic.

  1. Expand the JMS node.
  2. Expand the Distributed Destinations node. The Distributed Destinations table displays in the right pane showing all the distributed queues and topics.
  3. Click the distributed topic that you want to delete a member from. The Distributed Topic table shows all the distributed topic members that belong to the distributed topic.
  4. Click the Delete icon in the row of the distributed topic member that you want to delete. A dialog prompts you to confirm your deletion request.
  5. If you want to also remove the underlying physical queue, select the Also Delete check box.
  6. Click Remove to delete the distributed topic member (and the underlying physical topic if selected).
  7. The Distributed Topic table redisplays in the right pane. The distributed topic member is deleted from the Distributed Topic table.

Monitoring Distributed Destinations

When monitoring distributed destinations, you may see proxy topic members or system subscriptions, which are automatically created for the topic or queue members. For more information see, Monitoring Distributed Destination System Subscriptions and Proxy Topic Members.

 

Accessing Foreign JMS Providers

WebLogic JMS enables you to reference foreign (i.e., external) JMS providers within a local WebLogic JNDI tree. Using the Foreign JMS Server node, you can quickly map a foreign JMS provider so that its connection factories and destinations appear in the WebLogic JNDI tree as a local JMS objects. A Foreign JMS Server configuration can also be used to reference remote instances of WebLogic Server in another cluster or domain in the local WebLogic JNDI tree.

The following sections provide more information on how the Foreign JMS Server works, configuration instructions, and a sample configuration for accessing a remote MQSeries JNDI provider.

How WebLogic JMS Accesses Foreign JMS Providers

When a foreign JMS server is deployed, it creates local connection factory and destination objects in WebLogic Server JNDI. Then when a foreign JMS connection factory or destination object is looked up on the local server, that object performs the actual lookup on the remote JNDI directory, and the foreign object is returned from that directory.

This method makes it easier to configure multiple Messaging Bridge destinations, since the foreign JMS server moves the JNDI Initial Context Factory and Connection URL configuration details outside of your Messaging Bridge destination configurations. You need only provide the foreign Connection Factory and Destination JNDI name for each object.

The ease-of-configuration concept also applies to configuring WebLogic Servlets, EJBs, and Message-Driven Beans (MDBs) with WebLogic JMS. For example, the weblogic-ejb-jar.xml file in the MDB can have a local JNDI name, and you can use the foreign JMS server to control where the MDB receives messages from. For example, you can deploy the MDB in one environment to talk to one JMS destination and server, and you can deploy the same weblogic-ejb-jar.xml file to a different server and have it talk to a different JMS destination without having to unpack and edit the weblogic-ejb-jar.xml file.

Creating a Foreign JMS Server

A Foreign JMS Server represents a JNDI provider that is outside the WebLogic JMS server. It contains information that allows a local WebLogic Server to reach a remote JNDI provider, thereby allowing for a number of foreign JMS connection factory and destination objects to be defined on one JNDI directory.

After defining a foreign JMS server, you can configure connection factory and destination objects. You can configure one or more connection factories and destinations (queues or topics) for each foreign JMS server.

To configure a foreign JMS server, follow these steps:

  1. Expand the JMS node in the navigation tree, and then click the Foreign JMS Servers node.
  2. Click the Configure a new Foreign JMSServer text link in the right pane. A dialog shows the tabs associated with configuring a new Foreign JMS server.
  3. On the Configuration General tab, enter values in the Name, JNDI Initial Context Factory, JNDI Connection URL, and JNDI Properties attribute fields.

    For a detailed description of the general Foreign JMS Server attributes, see Foreign JMS Server --> Configuration --> General.

    Note: The JNDI Properties values may be a name=value list of properties, separated by commas.


     

  4. Click Create to create a JMS server instance with the name you specified in the Name field. The new instance is added under the Foreign JMS Servers node in the navigation tree, and a Foreign JMS Connection Factories node and Foreign JMS Destinations node are automatically added under the new foreign JMS server instance.
  5. On the Targets tab, select a standalone WebLogic Server instance or a cluster on which to deploy the foreign JMS server.
  6. Click Apply to target the foreign JMS server.

Continue by configuring a connection factory and destination objects. You can configure one or more connection factories and destinations (queues or topics) for each foreign JMS server.

Creating a Foreign JMS Connection Factory

A Foreign JMS Connection Factory contains the JNDI name of the connection factory in the remote JNDI provider, the JNDI name that the connection factory is mapped to in the local WebLogic Server JNDI tree, and an optional user name and password.

The foreign JMS connection factory creates non-replicated JNDI objects on each WebLogic Server instance that the parent foreign JMS server is targeted to. (To create the JNDI object on every node in a cluster, target the foreign JMS server to the cluster.)

To configure a foreign JMS connection factory, follow these steps:

  1. Expand the Foreign JMS Servers node, and then expand the Foreign JMS Connection Factories node.
  2. Click the Configure a new Foreign JMSConnection Factory text link. A dialog displays in the right pane showing the tabs associated with configuring a new foreign JMS connection factory.
  3. On the Configuration General tab, enter values in the Name, Local JNDI Name, Remote JNDI Name, User Name, and Password attribute fields.

    For a detailed description of the general Foreign JMS Connection Factory attributes, see Foreign JMS Connection Factory --> Configuration --> General.


     

    Note: The user name and password are only used when the Foreign JMS Connection Factory is used inside a resource-reference in an EJB or a servlet, and when the Container mode of authentication is used.

  4. Click Create to create a foreign JMS connection factory instance with the name you specified in the Name field. The new instance is added under the Foreign JMS Connection Factory node in the navigation tree.

Continue by configuring the destination objects. You can configure one or more destinations (queues or topics) for each foreign JMS server.

Creating a Foreign JMS Destination

A Foreign JMS Destination represents either a queue or a topic. It contains the destination JNDI name that is looked up on the foreign JNDI provider and the JNDI name that the destination is mapped to on the local WebLogic Server. When the foreign destination is looked up on the local server, a lookup is performed on the remote JNDI directory, and the destination object is returned from that directory.

To configure a foreign JMS destination, follow these steps:

  1. Expand the Foreign JMS Servers node, and then expand the Foreign JMS Destinations node.
  2. Click the Configure a new Foreign JMSDestination text link. A dialog displays in the right pane showing the tabs associated with configuring a foreign destination.
  3. On the Configuration General tab, enter values in the Name, Local JNDI Name and Remote JNDI Name attribute fields.

    For a detailed description of the general Foreign JMS Destination attributes, see Foreign JMS Destination --> Configuration --> General.


     

  4. Click Create to create a foreign JMS destination instance with the name you specified in the Name field. The new instance is added under the Foreign JMS Destinations node in the navigation tree.

Sample Configuration for MQSeries JNDI

Table 1-1 provides a possible a sample configuration when accessing a remote MQSeries JNDI provider.

Table 1-1 Sample MQSeries Configuration

Foreign JMS Object

Attribute Names

Sample Configuration Data

Foreign JMS Server

Name

JNDI Initial Context Factory

JNDI Connection URL

JNDI Properties

MQJNDI

com.sun.fscontext.RefFSContextFactory

file:/MQJNDI/

(If necessary, enter a comma-separated name=value list of properties.)

Foreign JMS
Connection Factory

Name

Local JNDI Name

Remote JNDI Name

Username

Password

MQ_QCF

mqseries.QCF

QCF

weblogic_jms

weblogic_jms

Foreign JMS
Destination 1



Foreign JMS
Destination 2

Name

Local JNDI Name

Remote JNDI Name


Name

Local JNDI Name

Remote JNDI Name

MQ_QUEUE1

mqseries.QUEUE1

QUEUE_1


MQ_QUEUE2

mqseries.QUEUE2

QUEUE_2

 

For detailed information about foreign server, connection factory, and attributes, and the valid and default values for them, refer to the following sections:

 

Back to Top Previous Next