The WebLogic Server implementation of JMS is an enterprise-class messaging system that is tightly integrated into WebLogic Server. It fully supports the JMS specification, and also provides numerous WebLogic Server JMS Extensions that go beyond the standard JMS APIs. For more information on WebLogic Server JMS and other related WebLogic Server messaging components, refer to the following guides:
Developing JMS Applications for Oracle WebLogic Server for a guide to JMS API programming with WebLogic Server.
Administering JMS Resources for Oracle WebLogic Server for information about configuring and managing JMS resources.
Administering the Store-and-Forward Service for Oracle WebLogic Server for information about the benefits and usage of the Store-and-Forward service with WebLogic Server JMS.
Using the WebLogic Persistent Store for information about the benefits and usage of the system-wide WebLogic Persistent Store with WebLogic Server JMS.
Configuring and Managing the WebLogic Messaging Bridge for information about a forwarding mechanism that provides interoperability between WebLogic Server JMS implementations, as well as between WebLogic Server JMS and other messaging products.
Note:
If you are logged into a domain partition, navigate from the Domain Partition menu.
This chapter includes the following sections:
JMS servers act as management containers for JMS queue and topic resources within JMS modules that are specifically targeted to JMS servers. You can create, monitor, control, and configure JMS servers.
This section includes the following tasks:
JMS servers are environment-related configuration entities that act as management containers for JMS queue and topic destinations in JMS modules that are targeted to them. Multiple JMS modules can be targeted to each JMS server in a domain.
To create a JMS server:
On the General Settings page, define the following settings for this JMS server:
In Name, enter a name for this JMS server.
In Scope, select the scope in which you would like this new JMS server to be created.
In Persistent Store, select a pre-configured custom file or JDBC store that will be used by the JMS server or click the Create a Store button to create a store on the fly.
If you leave this field set to none, then the JMS server will use the default file store that is automatically configured on each targeted server instance. For more information about configuring stores, see Configure a file store.
Note:
When a JMS server is targeted to:
A migratable target, it cannot use the default store, so a custom store must be configured and targeted to the same migratable target.
A dynamic cluster, a custom persistent store must target the same dynamic cluster or the default store available on each dynamic cluster member.
For more information about these fields, see Configuration Options.
On the Targets page, select the server instance, dynamic cluster, or migratable server target on which to deploy the JMS server.
You can monitor statistics for runtime information for active JMS servers in your domain. You can also access runtime information for a JMS server's destinations, transactions, connections, and server session pools.
To monitor JMS servers deployed to this domain:
You can monitor a variety of runtime statistics for each JMS server in your domain, such as the JMS server's paging store, active destinations, active transactions, active connections, and session pools. View the statistics for a JMS server to look for unusual activity, such as an abnormal number of messages waiting on a destination.
To monitor a specific JMS server:
A session defines a serial order for both the messages produced and the messages consumed, and can create multiple message producers and message consumers. The same thread can be used for producing and consuming messages.
To monitor session information for a JMS connection:
You can temporarily pause all runtime message production, insertion (in-flight messages), and consumption operations on all destinations targeted to a JMS server. These message pausing options let you assert administrative control of the JMS subsystem behavior in the event of an external resource failure.
For example, by temporarily pausing message production and insertion on destinations, you can effectively drain all the existing messages for troubleshooting purposes, and then resume production and insertions once the issue has been resolved.
To control messages on a JMS server:
You can temporarily pause runtime message production, insertion (in-flight messages) and consumption operations on selected destinations targeted to a JMS server.
To control active destinations on a JMS server:
You can force commits or rollbacks on selected transactions running on a JMS server.
To control active transactions on a JMS server:
A JMS connection represents an open communication channel between an application and the messaging system and is used to create a session for producing and consuming messages. For troubleshooting purposes, you can destroy selected connections on a JMS server.
To destroy a JMS connection on a JMS sever:
After you create a JMS server, you can define optional general properties for message paging, specify a template to use when your applications create temporary destinations, and a desired pausing interval between active scans of destinations for expired messages.
To configure general settings for a JMS server:
After you create a JMS server, you can define the upper and lower byte and/or message thresholds for destinations in JMS modules that targeted to this JMS server. Exceeding these thresholds will trigger events such as generating log messages and starting message flow control. In the Quota section, you can specify a maximum size allowed for messages and the number of messages and/or bytes available to a JMS server. You can also select a blocking policy to determine whether the JMS server delivers smaller messages before larger ones when a destination has exceeded its maximum number of messages.
To configure thresholds and quotas for a JMS server:
A JMS session pool enables an application to process messages concurrently. Once you have defined a JMS server, optionally, you can configure one or more session pools for each JMS server.
To create a new JMS session pool:
A JMS session pool enables an application to process messages concurrently. Once you have defined a JMS server, optionally, you can configure one or more session pools for each JMS server.
To view configuration information for the session pools that have been created for a JMS server:
To view configuration information for the connection consumers associated with a specific JMS session pool:
Connection consumers are queues or topics that retrieve JMS server sessions and process messages. After you define a session pool, configure one or more connection consumers for each session pool.
To create a new consumer:
Connection consumers are queues or topics that retrieve JMS server sessions and process messages. After you define a session pool, configure one or more connection consumers for each session pool.
This section includes the following topics:
The Store-and-Forward (SAF) service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. If the destination is not available at the moment the messages are sent, either because of network problems or system failures, then the messages are saved on a local server instance and are forwarded to the remote destination once it becomes available.
SAF agents are responsible for store-and-forwarding messages between local sending and remote receiving endpoints. A SAF agent can be configured to have only sending capabilities, receiving capabilities, or both. WebLogic Server SAF only requires a sending agent on the sending side for JMS messages. Whereas, Web Services Reliable Messaging (WSRM) SAF requires both a sending agent and a receiving agent.
This section includes the following tasks:
The Store-and-Forward (SAF) service uses SAF agents to deliver messages reliably between applications that are distributed across WebLogic Server instances. A SAF agent can be configured to have only sending capabilities, receiving capabilities, or both. JMS SAF only requires a sending agent on the sending side for JMS messages. Whereas, WSRM SAF requires both a sending agent and a receiving agent.
To create a Store-and-Forward agent:
On the General Settings page, define the following settings for this SAF agent:
In Name, enter a name for this SAF agent.
In Scope, select the scope in which you would like this new SAF agent to be created.
In Persistent Store, select a custom persistent store if you want a dedicated store for SAF messages or click Create a New Store to configure a new custom store.
If you leave this field set to none, then the SAF agent will use the default file store that is automatically configured on each targeted server instance. For more information about configuring stores, see Configure a file store.
Note:
When a SAF agent is targeted to a migratable target, it cannot use the default store. Therefore, a custom store must be configured and targeted to the same migratable target.
In Agent Type, select one of the following:
Sending-only: Configures an agent that stores messages in persistent storage, forwards messages to the receiving side, and re-transmits messages when acknowledgements do not come back in time.
Receiving-only: Configures an agent that detects and eliminates duplicate messages sent by a receiving agent, and delivers messages to the final destination.
Both: Configures an agent that has sending and receiving agent functionality.
Note:
JMS SAF users should select Sending-only since JMS SAF doesn't require a configured receiving agent.
For more information about these fields, see Configuration Options.
On the Targets page, select the server instance, cluster, or migratable target where you want to deploy the SAF agent.
A migratable target is a logical target that serves as a grouping of services, such as a SAF agent, and which is active on only server member in a cluster. High availability is achieved by migrating a migratable target from one server member to another when a problem occurs on the original server.
Note:
Oracle recommends targeting the SAF agent to a migratable target, so that a member server will not be a single point of failure. However, if a SAF agent is targeted to a migratable target, it cannot be targeted to any other server targets, including an entire cluster.
You can monitor a variety of runtime statistics for each SAF agent in your domain, including remote endpoints and conversations.
To view the current statistics for a specific SAF agent:
You can temporarily pause runtime message activity on SAF agents.
To control message operations on a SAF agent:
You can control message operations for active remote endpoints associated with a SAF agent.
To control remote endpoints for a SAF agent:
You can terminate active conversations associated with a SAF agent.
To destroy SAF conversations:
To configure general settings for a SAF sending or receiving agent:
JMS system resources are configured and stored as modules similar to standard Java EE modules. Such resources include queues, topics, connection factories, templates, destination keys, quota, distributed queues, distributed topics, foreign servers, and JMS Store-and-Forward (SAF) parameters.
System modules are globally available for targeting to server instances and clusters configured in the domain, and therefore are available to all applications deployed on the same targets and to client applications.
Note:
JMS configuration resources can also be managed as deployable application modules, either with a Java EE application as a packaged module, which is available only to the enclosing application, or as a standalone module that provides global access to the resources defined in that module. For more information about configuring JMS application modules, see Configuring JMS Application Modules for Deployment in Administering JMS Resources for Oracle WebLogic Server.
This section includes the following tasks:
JMS system resources are configured and stored as modules similar to standard Java EE modules. Such resources include queues, topics, connection factories, templates, destination keys, quota, distributed queues, distributed topics, foreign servers, and JMS Store-and-Forward (SAF) parameters.
To create a JMS system resource:
On the Resource Type page, choose the type of JMS resource that you would like to create. You can choose to create the following JMS resource types:
Connection Factory: defines a set of connection configuration settings that enable JMS clients to create JMS connections.
Destination Key: defines a sort order for messages as they arrive on destinations.
Quota: controls the allotment of system resources available to destinations.
JMS Template: provides an efficient means of defining multiple queues and topics with similar configuration settings.
JMS Queue: defines a point-to-point (PTP) destination, which enables one application to send a message to another.
Uniform Distributed Queue: represents a single unit of JMS queues that is accessible as a single, logical queue to a client.
JMS Topic: defines a publish/subscribe (pub/sub) destination, which enables an application to send a message to multiple applications.
Uniform Distributed Topic: represents a single unit of JMS topics that is accessible as a single, logical topic to a client.
Remote SAF Context: specifies the SAF login context that the SAF imported queue or topic uses to connect to a remote destination.
SAF Error Handler: specifies the action to be taken when the SAF service fails to forward messages to a remote destination.
SAF Imported Destinations: represents a collection of SAF queues and topics that locally represent JMS queues or topics on a remote server instance or cluster.
Foreign Server: represents a third-party JMS provider that is outside WebLogic Server.
On the JMS System Module page, select a JMS system module for this JMS resource:
In JMS Module, click the icon to select the JMS system module in which you would like to create this JMS resource from the JMS module table.
If the table is empty or does not contain the JMS module you need, then click Create a New JMS Module to create a JMS module, and then select the JMS module from the table.
The Scope field identifies the scope of the selected JMS module.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your JMS system resource. Properties depend on the JMS system resource type:
On the Properties page, define the settings for your connection factory:
Resource Type identifies the JMS resource type.
In Name, enter a name for the connection factory.
Once you create a connection factory, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In JNDI Name, enter a name for accessing the connection factory within the JNDI name space. Applications use the JNDI Name to look up the connection factory.
If you do not specify a JNDI name for the connection factory, then it will not be available for JNDI lookup even after the connection factory has been targeted to a server resource. Therefore, you will only be able to access the connection factory in an application-scoped context.
In Notes, enter notes about the configuration for this connection factory.
In Client ID Policy, select Restricted if only one connection that uses this policy can exist in a cluster at any given time for a particular Client ID. Select Unrestricted if connections created using this policy can specify any Client ID, even when other restricted or unrestricted connections already use the same Client ID.
In Subscription Sharing Policy, select Exclusive if all subscribers created using this connection factory cannot share subscriptions with any other subscribers. Select Sharable if subscribers created using this connection factory can share their subscriptions with other subscribers, regardless of whether those subscribers are created using the same connection factory or a different connection factory.
Consumers can share a non-durable subscriptions only if they have the same Client ID and Client ID Policy; consumers can share a durable subscription only if they have the same Client ID, Client ID Policy, and Subscription Name.
In Prefetch Mode for Synchronous Consumer, specifies whether a synchronous consumer will prefetch messages sent from the server to the client in one server access.
In Maximum Messages per Session, specify the maximum number of messages that can exist for an asynchronous session and that have not yet been passed to the message listener. When the Synchronous Prefetch Mode is enabled, this value also affects synchronous sessions with a message consumer that will prefetch messages in one server access.
Under Distributed Destination Load Balancing, select the appropriate checkboxes if you want to enable load balancing and server affinity.
Under Transaction, in Enable XA connection factory, select whether an XA queue or XA topic connection factory is used, instead of a standard queue or topic connection factory.
An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions.
In Transacted session transaction timeout, specify the timeout value (in seconds) for all transactions on connections created with this connection factory.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your destination key:
Resource Type identifies the JMS resource type.
In Name, enter a name for this destination key.
In Notes, enter notes about the configuration of this destination key.
In Sort Key, select a message sort key from the menu or enter the name of a message header field on which to sort.
In Key Type, select the expected property type for the sort key. (This setting is ignored for message header field keys, which have an implied type.)
In Direction, select the direction in which the key will sort messages (ascending or descending).
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your quota:
Resource Type identifies the JMS resource type.
In Name, enter a name for this quota.
In Notes, enter notes about the configuration for this quota
In Policy, select the delivery policy to determine whether to allow smaller message send requests to be satisfied before larger ones when a destination has exceeded its message quota.
The default FIFO (first in, first out) policy blocks subsequent newer sender requests until there is enough space for the first request in line, or denies the newer requests with a quota exception if the newer requests time out.
The Preemptive policy allows newer smaller send requests to preempt previous larger requests when there is sufficient space for smaller messages on the destination, but not sufficient space for the older larger requests.
Select Shared by multiple destinations to specify whether this quota is shared by destinations that refer to it.
In Total number of bytes that can be stored in a destination, enter the total number of bytes that can be stored in a destination that uses this quota.
In Number of messages that can be stored in a destination, enter the total number of messages that can be stored in a destination that uses this quota.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your JMS template:
Resource Type identifies the JMS resource type.
In Name, enter a name for this JMS template.
In Notes, enter notes about the configuration for this JMS template.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your JMS queue:
Resource Type identifies the JMS resource type.
In Name, enter a name for the queue.
Once you create a queue, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this JMS queue.
In JNDI Name, enter a name for accessing the queue within the JNDI name space. Applications use the JNDI Name to look up the queue.
If you do not specify a JNDI name for the queue, then it will not be available for JNDI lookup even after it has been targeted to a JMS server. Therefore, you will only be able to access the queue using the javax.jms.queueSession.createqueue() API or in an application-scoped context.
If you are using a configured JMS template to define the queue's settings, in Template, select the template for the queue.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your uniform distributed queue:
Resource Type identifies the JMS resource type.
In Name, enter a name for the uniform distributed queue.
Once you create a uniform distributed queue, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this uniform distributed queue.
In JNDI Name, enter the JNDI name used to look up the uniform distributed queue within the JNDI namespace. Applications use the JNDI Name to look up the distributed queue.
If you do not specify a JNDI name for the distributed queue, then it will not be available for JNDI lookup even after it has been targeted to a server resource. Therefore, you will only be able to access the distributed queue using the javax.jms.queueSession.createqueue() API or in an application-scoped context.
Optionally, in Template, specify the template to use when creating this uniform distributed queue. Templates provide an efficient means of defining multiple destinations with similar configuration values.
Under Distributed Configuration, in Load Balancing Policy, specify a policy (Round Robin or Random) for how messages are distributed to the members of this distributed queue.
In Unit-of-Ordering Routing, specify how the distributed queue members are selected as the destination for a message. If set to Hash, then the producer computes the queue member. If set to Path Service, then the configured Path Service determines the queue member.
In Set Forward Delay, select Forward delay to specify the amount of time, in seconds, that a queue member with messages, but with no consumers, will wait before forwarding its messages to other queue members that do have consumers, or select No messages are forwarded.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your JMS topic:
Resource Type identifies the JMS resource type.
In Name, enter a name for the topic.
Once you create a topic, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this JMS topic.
In JNDI Name, enter a name for accessing the topic within the JNDI name space. Applications use the JNDI Name to look up the topic.
If you do not specify a JNDI name for the topic, then it will not be available for JNDI lookup even after it has been targeted to a JMS server. Therefore, you will only be able to access the topic using the javax.jms.topicSession.createtopic() API or in an application-scoped context.
If you are using a configured JMS template to define the topic's settings, in Template, select the template for the topic.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your uniform distributed topic:
Resource Type identifies the JMS resource type.
In Name, enter a name for the uniform distributed topic.
Once you create a uniform distributed topic, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this uniform distributed topic.
In JNDI Name, enter the JNDI name used to look up the uniform distributed topic within the JNDI namespace. Applications use the JNDI Name to look up the distributed topic.
If you do not specify a JNDI name for the distributed topic, then it will not be available for JNDI lookup even after it has been targeted to a server resource. Therefore, you will only be able to access the distributed topic using the javax.jms.topicSession.createtopic() API or in an application-scoped context.
Optionally, in Template, select a template to define configuration values.
Under Distributed Configuration, in Forwarding Policy, specify Replicated to allow a member to replicate (forward) information to other members of the distributed topic. Specify Partitioned to prevent forwarding to other members of the distributed topic.
In Load Balancing Policy, specify how messages are distributed to the members of this destination.
In Unit-of-Order Routing, specify how the distributed topic members are selected as the destination for a message. If set to Hash, then the producer computes the topic member. If set to Path Service, then the configured Path Service determines the topic member.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your remote SAF context:
Resource Type identifies the JMS resource type.
In Name, enter the name for the remote SAF context.
In Notes, enter notes about the configuration for this remote SAF context.
In Compression Threshold, specify the number of bytes for a serialized message body so that any message that exceeds this limit triggers message compression.
In Reply to Remote SAF Context, specify the name of the remote SAF context used by the replyTo destination in the remote cluster or server.
Select Specify the Login Context to specify a URL, user name and password when using this remote SAF context.
In URL, specify the URL that the imported queue or topic uses to connect to the remote destination.
In User Name, specify the user name that the imported queue or topic gives to the remote destination.
In Password, enter the password that the imported queue or topic gives to the remote destination.
In Confirm Password, confirm the specified password.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your SAF error handling resource:
Resource Type identifies the JMS resource type.
In Name, enter a name for the SAF error handling resource.
Once you create a SAF error handling resource, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this SAF error handling resource.
In SAF Error Handling Policy, select the policy type for this SAF error handling resource:
Discard:
Log: specify the log format or add a new log format for this SAF error handling resource.
Redirect: select an error destination for this SAF error handling resource.
Always-forward:
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your SAF import destination:
Resource Type identifies the JMS resource type.
In Name, enter a name for the SAF imported destinations resource.
Once you create a SAF imported destination, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this SAF import destination.
In JNDI Prefix, specify a prefix that is appended to the remote destination JNDI name.
If you do not specify a JNDI name for the SAF imported destination, then it will not be available for JNDI lookup even after the SAF imported destination has been targeted to a server resource. Therefore, you will only be able to access the SAF imported destination in an application-scoped context.
In Remote SAF Context, select a remote context instance. If necessary, create a new remote SAF context and then select it from the menu.
In SAF Error Handling, select an error handling instance. If necessary, create a new SAF error handling resource and then select it from the menu.
In Message Unit-of-Order Routing,
In SAF Default Time-to-Live, specify a default Time-to-Live value, in milliseconds, for JMS messages. The expiration time set on JMS messages will override this value unless the Enable SAF Default Time-to-Live checkbox is selected.
Select Enable SAF Default Time-to-Live to override the expiration time set on JMS messages with the value specified this field.
For more information about these fields, see Configuration Options.
On the Properties page, define the settings for your foreign server:
Resource Type identifies the JMS resource type.
In Name, enter a name for the foreign server.
Once you create a foreign server, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
In Notes, enter notes about the configuration for this foreign server.
In JNDI Initial Context Factory, enter the name of the class that must be instantiated to access the JNDI provider. This class name depends on the provider and vendor that are being used.
In JNDI Connection URL, enter the URL that WebLogic Server uses to contact the JNDI provider. The syntax of this URL depends on which JNDI provider is being used. For WebLogic JMS, leave this field blank if you are referencing WebLogic JMS objects within the same cluster.
In JNDI Properties Credential, specify any credentials that must be set for the JNDI provider. These Credentials will be part of the properties that will be passed directly to the constructor for the JNDI provider's InitialContext class. When connecting to a remote domain, you must specify the secure password for the domain (e.g., remote_domain_password) along with the domain username in the JNDI Properties field.
In Confirm JNDI Properties Credential, re-enter any credentials that must be set for the JNDI provider.
In JNDI Properties, specify any additional properties that must be set for the JNDI provider.
These properties will be passed directly to the constructor for the JNDI provider's InitialContext class. When connecting to a remote domain, you must specify the secure username for the domain using the following format: java.naming.security.principal=remote_domain_username
Note:
The JNDI Properties values may be a name=value list of properties, separated by commas.
For more information about these fields, see Configuration Options.
On the Targets page, specify the targeting policy for this JMS resource:
Select Default to the parent module's target to use the default targeting.
Select Subdeployment targeting to choose an existing subdeployment or to create a new one.
To select an existing subdeployment for the connection factory, select one from the Subdeployment Name menu. When a valid subdeployment is selected, its targeted JMS server(s), server(s), or cluster appear as selected in the Targets box. (A subdeployment with stand-alone destinations can only be targeted to a single JMS server.)
To create a new subdeployment for the connection factory, click the Create a New Subdeployment button. See ADD CREATE SUBDEPLOYMENT TAKSK HERE.
For more information about these fields, see Configuration Options.
You can view all the resources from all the JMS system modules created in the current WebLogic Server domain. You can also view monitoring information, including the resource's system module, JNDI name, targeted subdeployment resources, and the JMS server, WebLogic server, instance or cluster on which the resource is targeted.
For certain resources, you can monitor detailed statistical information or perform control operations.
To monitor all JMS system resources in the current domain:
A JMS queue is based on the point-to-point (PTP) messaging model, which 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.
You configure queues explicitly or by configuring a JMS template that can be used to define multiple queues with similar option settings, as described in Configure JMS templates.
Note:
To help manage recovered or rolled back messages, you can also configure a target error destination for messages that have reached their redelivery limit. However, the error destination must be targeted to same JMS server as the other queues in a module.
Some queue options are dynamically configurable. When options are modified at runtime, only incoming messages are affected; stored messages are not affected.
This section includes the following tasks:
After you create a queue, you can define general property values, such as selecting a destination key for sorting messages as they arrive on the queue, or a selecting JMS template if you are using one to configure properties for multiple queues.
To define general configuration settings for a queue in a JMS system module:
After you create a queue, you can define advanced property values, such as specifying unit-of-order parameters, attaching the credentials of message senders, or defining unit-of-work parameters.
To define advanced configuration settings for a queue in a JMS system module:
After you create a queue, you can change the default message delivery failure values, like defining a message redelivery limit, selecting a message expiration policy, and specifying an error destination for expired or undeliverable messages.
To define general configuration settings for a queue in a JMS system module:
After you create a queue, you can define message delivery override values that can override those specified by a message producer.
To configure message delivery overrides for a queue:
After you create a queue, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this queue:
After you create a queue, you can change the default upper and lower byte and/or message thresholds for the queue. Exceeding these thresholds will trigger events, such as generating log messages and starting message flow control. You can also specify a maximum size allowed for messages on the queue, and select a pre-configured quota, which determines the maximum number of bytes or messages that the queue is allowed to store to conserve memory use.
If a JMS template is specified for this queue, then the default values imply that the actual value will come from the template, see Configure JMS template thresholds and quotas. A JMS server can also manage thresholds and certain quota settings for all destinations in a JMS module targeted to that JMS server, see Configure JMS server thresholds and quotas.
To configure thresholds and quotas for a queue in a JMS system module:
A distributed queue is a single unit of JMS queues that are accessible as a single, logical queue to a client (for example, a distributed queue has its own JNDI name). The members of the unit are usually distributed across multiple servers within a cluster, with each queue member belonging to a separate JMS server.
By configuring uniform distributed queues, WebLogic Server uniformly creates the necessary members on the JMS servers to which a JMS module is targeted. This ensures the consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas across a cluster.
This section includes the following tasks:
To monitor statistics for all of the members of a uniform distributed queue in a JMS system module:
After you create a uniform distributed queue, you can modify and define general property values, such as selecting a destination key for sorting messages as they arrive on the members of the distributed queue.
To define general configuration settings for a uniform distributed queue in a JMS system module:
After you create a distributed queue, you can define advanced property values, such as specifying unit-of-order parameters and attaching the credentials of message senders.
To define advanced configuration settings for a uniform distributed queue in a JMS system module:
After you create a uniform distributed queue, you can change the default message delivery failure values, like defining a message redelivery limit, selecting a message expiration policy, and specifying an error destination for expired or undeliverable messages.
To define general configuration settings for a uniform distributed queue in a JMS system module:
After you create a uniform distributed queue, you can define message delivery override values that can override those specified by a message producer.
To configure message delivery overrides for a uniform distributed queue:
After you create a uniform distributed queue, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this uniform distributed queue:
After you create a uniform distributed queue, you can change the default upper and lower byte and/or message thresholds for the distributed queue members. Exceeding these thresholds will which trigger events such as generating log messages and starting message flow control. You can also select a pre-configured quota, which specifies the maximum number of bytes or messages that the distributed queue is allowed to store to conserver memory use. You can also specify a maximum size allowed for messages on the distributed queue.
To configure thresholds and quotas for a uniform distributed queue in a JMS system module:
A JMS topic is based on the publish/subscribe (pub/sub) messaging model, which 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.
You configure topics explicitly or by configuring a JMS template that can be used to define multiple topics with similar option settings, as described in Configure JMS templates.
Note:
To help manage recovered or rolled back messages, you can also configure a target error destination for messages that have reached their redelivery limit. The error destination must be targeted to same JMS server as the other topics in the module.
Some topic options are dynamically configurable. When options are modified at runtime, only incoming messages are affected; stored messages are not affected.
This section includes the following tasks:
To view configuration details of a durable subscriber running on a JMS topic or uniform distributed topic:
For troubleshooting purposes, runtime message production, consumption, and insertion activity can be temporarily paused on topics targeted to a JMS system module.
To control messages on topics in a JMS system module:
After you create a topic, you can define general property values, such as selecting a destination key for sorting messages as they arrive on the topic, or a selecting JMS template if you are using one to configure properties for multiple topics.
To define general configuration settings for a topic in a JMS system module:
After you create a topic, you can define advanced general property values, such as specifying unit-of-order parameters and attaching the credentials of message senders.
To define advanced configuration settings for a topic in a JMS system module:
After you create a topic, you can change the default message delivery failure values, like defining a message redelivery limit, selecting a message expiration policy, and specifying an error destination for expired or undeliverable messages.
To define general configuration settings for a topic in a JMS system module:
After you create a topic, you can define message delivery override values that can override those specified by a message producer.
To configure message delivery overrides for a topic:
After you create a topic, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this topic:
After you configure a topic, you can define multicast parameters that enable the delivery of messages to a select group of hosts that subsequently forward the messages to subscribers.
To configure multicast options for this topic:
After you create a topic, you can change the default upper and lower byte and/or message thresholds for the topic. Exceeding these thresholds will trigger events, such as generating log messages and starting message flow control. You can also specify a maximum size allowed for messages on the topic, and select a pre-configured quota, which determines the maximum number of bytes or messages that the topic is allowed to store to conserve memory use.
If a JMS template is specified for this topic, then the default values imply that the actual value will come from the template, see Configure JMS template thresholds and quotas. A JMS server can also manage thresholds and certain quota settings for all destinations in a JMS module targeted to that JMS server, see Configure JMS server thresholds and quotas.
To configure thresholds and quotas for a topic in a JMS system module:
A distributed topic is a single unit of JMS topics that are accessible as a single, logical topic to a client (for example, a distributed topic has its own JNDI name). The members of the unit are usually distributed across multiple servers within a cluster, with each topic member belonging to a separate JMS server.
By configuring uniform distributed topics, WebLogic Server uniformly creates the necessary members on the JMS servers to which a JMS module is targeted. This ensures the consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas across a cluster.
This section includes the following tasks:
To monitor statistics for all of the members of a uniform distributed topic in a JMS system module:
After you create a uniform distributed topic, you can modify and define general property values, such as selecting a destination key for sorting messages as they arrive on the members of the distributed topic.
To define general configuration settings for a uniform distributed topic in a JMS system module:
After you create a uniform distributed topic, you can define advanced property values, such as specifying unit-of-order parameters and attaching the credentials of message senders.
To define advanced configuration settings for a uniform distributed topic in a JMS system module:
After you create a uniform distributed topic, you can change the default message delivery failure values, like defining a message redelivery limit, selecting a message expiration policy, and specifying an error destination for expired or undeliverable messages.
To define general configuration settings for a uniform distributed topic in a JMS system module:
After you create a uniform distributed topic, you can define message delivery override values that can override those specified by a message producer.
To configure message delivery overrides for a uniform distributed topic:
After you create a uniform distributed topic, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this uniform distributed topic:
After you configure a distributed topic, you can define multicast parameters that enable the delivery of messages to a select group of hosts that subsequently forward the messages to subscribers.
To configure multicast options for this uniform distributed topic:
After you create a uniform distributed topic, you can change the default upper and lower byte and/or message thresholds for the distributed topic members. Exceeding these thresholds will which trigger events such as generating log messages and starting message flow control. You can also select a pre-configured quota, which specifies the maximum number of bytes or messages that the distributed topic is allowed to store to conserver memory use. You can also specify a maximum size allowed for messages on the distributed topic.
To configure thresholds and quotas for a uniform distributed topic in a JMS system module:
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.
This section includes the following tasks:
To define general configuration settings for a connection factory in a JMS system module:
To define advanced configuration settings for a connection factory in a JMS system module:
After you configure a connection factory, you can define various default message delivery settings. For example, if a client does not specify certain delivery settings then the value of those settings can be controlled with the default delivery settings on this page. In addition, you can associate a unit-of-order with all sessions created from a factory configured with unit-of-order enabled, and, optionally, a name provided. As a result, all sessions created from this connection factory will have unit-of-order enabled. All messages produced from the same session will belong to the same unit-of-order. Messages from different sessions belong to different unit-of-orders.
To define default deliver settings for a connection factory in a JMS system module:
Flow control allows you to tell a JMS server or destination to slow down message producers when it determines that it is becoming overloaded. Specifically, when a JMS server or destination exceeds its specified bytes or messages thresholds, it instructs producers to limit their message flow (messages per second).
To configure message flow control on a connection factory:
As messages arrive on a specific destination, by default they are sorted in FIFO (first-in, first-out) order, which sorts ascending based on each message's unique JMSMessageID. However, you can use a destination key to configure a different sorting scheme for a destination, such as LIFO (last-in, first-out).
After you configure a destination key, you can select it from within a destination resource, such as a queue, topic, distributed queue, distributed topic, or JMS template if you are using templates to configure your destinations.
This section includes the following tasks:
To define general configuration settings for a destination key in a JMS system module:
JMS quotas are used to control the allotment of system resources available to destinations. For example, you can specify the number of bytes or messages that a destination is allowed to store, or specify whether the quota can be shared be all destinations that refer to it.
Once you configure a quota, you can select it on the Thresholds and Quota page from within a destination resource, such as a queue, topic, distributed queue, distributed topic, or JMS template if you are using templates to configure your destinations.
This section includes the following tasks:
To define general configuration settings for a quota in a JMS system module:
A JMS template provides an efficient means of defining multiple JMS queues and topics with similar configuration settings. Instead of re-entering configuration settings each time you define a new queue or topic, you can use a template and override the settings for which you want to assign a new value.
Once you configure a JMS template, you can select it from within a queue or topic resource.
This section includes the following tasks:
To view general configuration settings for a JMS template in a JMS system module:
After you create a template, you can define advanced property values, such as specifying unit-of-order parameters, attaching the credentials of message senders, or defining unit-of-work parameters.
To define advanced configuration settings for a JMS template in a JMS system module:
After you create a JMS template, you can change the default message delivery failure values for destinations, like defining a message redelivery limit, selecting a message expiration policy, and specifying an error destination for expired messages.
To configure message redelivery options for a JMS template in a JMS system module:
After you create a JMS template, you can define message delivery override values that can override those specified by a message producer.
To configure message delivery overrides for a JMS template in a JMS system module:
After you create a JMS template, you can enable the logging of message life cycle information for destinations into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure destination logging for a JMS template in a JMS system module:
After you configure a JMS template, you can define multicast parameters for topics that enable the delivery of messages to a select group of hosts that subsequently forward the messages to subscribers.
To configure multicast options for a JMS template in a JMS system module:
After you create a JMS template, you can define upper and lower message/byte threshold and quota values for queues and topics created from a JMS template.
To configure thresholds and quotas for a JMS template in a JMS system module:
A remote SAF context resource specifies the login context that the imported SAF queue or SAF topic uses to connect to a remote destination.
This section includes the following tasks:
To define general configuration settings for a SAF remote context in a JMS system module:
A SAF error handling resource specifies the action to be taken when the SAF service fails to forward messages to a remote destination.
This section includes the following tasks:
To define general configuration settings for a SAF error handler in a JMS system module:
SAF imported destinations are collections of SAF queues and topics that locally represent JMS queues or topics on a remote server instance or cluster. Each collection of imported destinations is associated with a remote SAF context. They can also share the same JNDI prefix, time-to-live default (message expiration time), and SAF error handling policy.
SAF queues are used for asynchronous and disconnected peer communications. Messages delivered to a SAF queue are temporarily stored for future delivery and are forwarded to a JMS queue on a remote server or cluster when it is reachable.
SAF topics are used for asynchronous and disconnected peer communications. Messages delivered to a SAF topic are temporarily stored for future delivery and are forwarded to a JMS topic on a remote server or cluster when it is reachable.
This section includes the following tasks:
To define general configuration settings for a foreign server in a JMS system module:
This section includes the following topics:
A SAF queue represents a JMS queue in a remote server or cluster. SAF queues are used for asynchronous and disconnected peer communications. Messages delivered to a SAF queue are temporarily stored for future delivery, and are forwarded to a JMS queue on a remote server or cluster when it is reachable.
To create a SAF queue for this SAF imported destination:
An imported SAF topic represents a topic in a remote server or cluster. SAF topics are used for asynchronous and disconnected peer communications. Messages delivered to a SAF topic are temporarily stored for future delivery, and are forwarded to a JMS topic on a remote server or cluster when it is reachable.
To create a SAF topic for this SAF imported destination:
A SAF queue represents a JMS queue in a remote server or cluster. SAF queues are used for asynchronous and disconnected peer communications. Messages delivered to a SAF queue are temporarily stored for future delivery, and are forwarded to a JMS queue on a remote server or cluster when it is reachable.
An imported SAF topic represents a topic in a remote server or cluster. SAF topics are used for asynchronous and disconnected peer communications. Messages delivered to a SAF topic are temporarily stored for future delivery, and are forwarded to a JMS topic on a remote server or cluster when it is reachable.
This section includes the following tasks:
To configure general configuration settings for this SAF queue:
After you create a SAF queue, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this SAF queue:
To configure general configuration settings for this SAF topic:
After you create a SAF topic, you can enable the logging of message life cycle information into a JMS message log file. A message life cycle is an external view of the basic events that a JMS message traverses through, such as message production, consumption, and removal. The content of the message log always includes message ID and correlation ID, but you can also configure information like message type and user properties.
To configure life cycle logging for messages on this SAF topic:
A foreign server represents a JNDI provider that is outside WebLogic Server. It contains information that allows a local WebLogic Server instance to reach a remote JNDI provider, thereby allowing for a number of foreign connection factory and destination objects to be defined on one JNDI directory.
After defining a foreign server, you can configure foreign connection factory and destination objects (queues or topics). You can configure one or more foreign connection factories and destinations for each foreign server.
This section includes the following tasks:
To define general configuration settings for a foreign server in a JMS system module:
A foreign 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 create a foreign destination:
To view configuration information for the foreign destinations that have been created for a foreign server:
A foreign destination (topic or queue) is a destination on a remote server. When this destination is looked up on the local server, a look-up will be performed automatically on the remote JNDI directory, and the object will be returned from that directory.
To configure a foreign destination:
A foreign 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 connection factory creates non-replicated JNDI objects on each WebLogic Server instance that the parent foreign server is targeted to. (To create the JNDI object on every node in a cluster, target the foreign server to the cluster.)
To create a foreign connection factory:
To view configuration information for the foreign connection factories that have been created for a foreign server:
A foreign connection factory is a connection factory that resides on another server instance and is accessible through JNDI. A remote connection factory can be used to refer to another instance of WebLogic Server running in a different cluster or server, or a foreign provider, as long as that provider supports JNDI.
To configure a foreign connection factory:
JMS resources are configured and stored as modules similar to standard Java EE modules. You can administratively configure and manage JMS modules as global system resources.
To create a JMS system module:
On the General Settings page, define the following settings for this JMS module:
In Name, enter a name for this JMS module.
In Scope, select the scope in which you would like this new JMS module to be created.
In Descriptor File, optionally enter a name for the JMS module's underlying descriptor file. The system will automatically add a "-jms.xml" extension to this name. If you do not provide a name, then a default name is assigned.
For more information about these fields, see Configuration Options.
On the Targets page, select the server instance or cluster target on which to deploy the JMS system module.
You can monitor the JMS system modules created for the current domain. The table specifies which resource types are part of each module, as well as the number of assigned resource types.
To monitor JMS modules:
JMS resources are configured and stored as modules similar to standard Java EE modules. Such resources include queues, topics, connection factories, templates, destination keys, quota, distributed queues, distributed topics, foreign servers, and JMS store-and-forward (SAF) parameters. You can administratively configure and manage JMS modules as global system resources.
This section includes the following tasks:
After creating 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 SAF (store-and-forward) parameters.
To configure the resources for a specific JMS system module:
You can create and manage subdeployments for your JMS resources. A subdeployment is a mechanism by which JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as JMS servers, server instances, SAF agents, or a cluster).
For example, you can group a connection factory with stand-alone queues or topics in a subdeployment targeted to a specific JMS server, which guarantees that all these resources are co-located to avoid extra network traffic. Another advantage of such a configuration would be if the targeted JMS server needs to be migrated to another WebLogic server instance, then the connection factory and all its connections will also migrate along with the JMS server's destinations. However, when stand-alone queues or topics are members of a subdeployment, a connection factory can only be targeted to the same JMS server.
To manage the subdeployments of a JMS module:
A subdeployment is a mechanism by which JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as JMS servers, server instances, SAF agents, or a cluster).
For example, you can group a connection factory with stand-alone queues or topics in a subdeployment targeted to a specific JMS server, which guarantees that all these resources are co-located to avoid extra network traffic. Another advantage of such a configuration would be if the targeted JMS server needs to be migrated to another WebLogic server instance, then the connection factory and all its connections will also migrate along with the JMS server's destinations. However, when stand-alone queues or topics are members of a subdeployment, a connection factory can only be targeted to the same JMS server.
To create a JMS module subdeployment:
A subdeployment is a mechanism by which JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as JMS servers, server instances, SAF agents, or a cluster).
To target a JMS module subdeployment:
After you create a JMS system module, you can deploy it on one or more servers, clusters, or even to specific servers within a cluster.
To target a JMS system module:
A path service is a persistent map that can be used to store the mapping of a group of messages to a messaging resource, such as a member of a distributed destination or a Store-and-Forward agent. It provides a way to enforce message ordering by pinning messages to a member of a cluster hosting servlets, distributed queue members, or Store-and-Forward agents.
This section includes the following tasks:
To create a path service:
On the General Settings page, define the following settings for this path service:
In Name, enter a name for this path service.
In Scope, select the scope in which you would like this new path service to be created.
In Persistent Store, select a custom persistent store if you want a dedicated store for SAF messages or click Create a New Store to configure a new custom store.
Otherwise, leave this field set to None when using the default Persistent Store since it requires no configuration. For more information about configuring stores, see Configure a file store.
Note:
When a path service is targeted to a migratable target, it cannot use the default store, so a custom store must be configured and targeted to the same migratable target. And, as a best practice, the path service and its store should be the only users of that migratable target.
For more information about these fields, see Configuration Options.
On the Targets page, select a cluster member or migratable target where you want to deploy the path service.
A migratable target is a logical target that serves as a grouping of services, such as a path service, and which is active on only server member in a cluster. High availability is achieved by migrating a migratable target from one server member to another when a problem occurs on the original server.
Note:
Oracle recommends targeting the path service to a migratable target, so that a member server will not be a single point of failure. A path service can also be automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services.
A path service is a persistent map that can be used to store the mapping of a group of messages to a messaging resource, such as a member of a distributed destination or a store-and-forward agent. It provides a way to enforce message ordering by pinning messages to a member of a cluster hosting servlets, distributed queue members, or Store-and-Forward agents.
This section includes the following tasks:
To configure general settings for a specific path service in the current domain:
To select the targets for a specific path service in the current domain:
A WebLogic messaging bridge is a forwarding mechanism between any two messaging products. Use a message bridge to provide interoperability between separate implementations of WebLogic JMS, or between WebLogic JMS and another messaging product.
This section includes the following tasks:
A messaging bridge instance communicates with the configured source and target bridge destinations. For each mapping of a source destination to a target destination, whether it is another WebLogic JMS implementation, or a third-party JMS provider, you must configure a messaging bridge instance. Each instance defines the source and target destination for the mapping, a message filtering selector, a quality of service (QOS), transaction semantics, and reconnection parameters.
To create a messaging bridge instance:
On the General Settings page, define the following settings for this messaging bridge:
In Name, enter a name for this messaging bridge.
In Scope, select the scope in which you would like this new messaging bridge to be created.
In Selector, specify the filter for messages that are sent across the messaging bridge instance.
In Quality of Service, select the QOS (quality of service) for this messaging bridge instance.
Select or deselect the Started checkbox to specify the initial operating state of a targeted messaging bridge instance.
For more information about these fields, see Configuration Options.
On the Source Bridge Destination page, select an existing source destination or create a new source destination.
If the drop-down box is empty or does not contain the source destination you need, then click New Destination to create a source destination, and then select the source destination from the drop-down box.
On the Target Bridge Destination page, select an existing target destination or create a new target destination.
If the drop-down box is empty or does not contain the target destination you need, then click New Destination to create a target destination, and then select the target destination from the drop-down box.
To monitor the messaging bridge instances that have been configured for the current domain:
To monitor the status of a specific messaging bridge instance configured for the current domain:
To configure general settings for a specific messaging bridge instance in the current domain:
The high availability settings are applicable for a bridge when it is:
Not targeted
Scoped to a member of a resource group or resource group template
Targeted to a cluster
The high availability settings are not applicable to a bridge when it is:
Targeted directly to a server (within a configured cluster or standalone)
Targeted to a migratable target
To configure high availability settings for a specific messaging bridge instance in the current domain:
To configure connection retry settings for a specific messaging bridge instance in the current domain:
To configure transactions for a specific messaging bridge instance in the current domain:
To select the targets for a specific messaging bridge instance in the current domain:
A JMS bridge destination is a source or target destination in a JMS messaging product. Configure a JMS bridge destination instance for each JMS messaging source and target destination that connects to a messaging bridge.
This section includes the following tasks:
A JMS bridge destination instance defines the actual source and target JMS bridge destinations within the WebLogic domain.
You need to configure a JMS bridge destination instance for each actual source and target destination to be mapped to a messaging bridge instance. Therefore, when you finish defining attributes for a source JMS bridge destination, repeat these steps to configure a target JMS bridge destination, or vice versa.
To create a JMS bridge destination:
On the General Settings page, define the following settings for this JMS bridge destination:
In Name, enter a name for this JMS bridge destination.
In Scope, select the scope in which you would like this new JMS bridge destination to be created.
In Adapter JNDI Name, specify the JNDI name of the adapter used to communicate with the bridge destinations.
In Connection URL, specify the connection URL for this JMS bridge destination.
In Connection Factory JNDI Name, specify the connection factory's JNDI name for this JMS bridge destination.
In Destination JNDI Name, specify the destination JNDI name for this JMS bridge destination.
For more information about these fields, see Configuration Options.
To monitor the JMS bridge destinations configured in the current domain: