2-4 Configuring and Managing JMS for Oracle WebLogic Server
the destinations. As a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all of its destinations.
JMS servers are persisted in the domains config.xml file and multiple JMS servers can be configured on the various WebLogic Server instances in a cluster, as long as
they are uniquely named. Client applications use either the JNDI tree or the java:compenv naming context to look up a connection factory and create a
connection to establish communication with a JMS server. Each JMS server handles requests for all targeted modules destinations. Requests for destinations not handled
by a JMS server are forwarded to the appropriate server instance.
2.4.1 JMS Server Behavior in WebLogic Server 9.x and Later
The current release of JMS server behavior differs in certain respects from the behavior in pre-9.x releases:
■
Because destination resources are encapsulated in JMS modules, they are not nested under JMS servers in the configuration file. However, a sub-targeting
relationship between JMS servers and destinations is maintained because each standalone destination resource within a JMS module is always targeted to a
single JMS server. This way, JMS servers continue to manage persistent messages, durable subscribers, message paging, and, optionally, quotas for their targeted
destinations. Multiple JMS modules can be targeted to each JMS server in a domain.
■
JMS servers support the default persistent store that is available to multiple subsystems and services within a server instance, as described in
Section 2.6.1, Persistent Stores.
– JMS servers can store persistent messages in a host servers default file store
by enabling the Use the Default Store option. In prior releases, persistent messages were silently downgraded to non-persistent if no store was
configured. Disabling the Use the Default Store option, however, forces persistent messages to be non-persistent.
– In place of the deprecated JMS stores JMS file store and JMS JDBC store, JMS
servers now support user-defined WebLogic file stores or JDBC stores, which provide better performance and more capabilities than the legacy JMS stores.
The legacy JMS stores are supported for backward compatibility.
■
JMS servers support an improved message paging mechanism. For more information on message paging, see Performance and Tuning for Oracle WebLogic
Server.
– The configuration of a dedicated paging store is no longer necessary because
paged messages are stored in a directory on your file system -- either to a user-defined directory or to a default paging directory if one is not specified.
– Temporary paging of messages is always enabled and is controlled by the
value set on the Message Buffer Size option. When the total size of non-pending, unpaged messages reaches this setting, a JMS server will
attempt to reduce its memory usage by paging out messages to the paging directory.
■
You can pause message production or message consumption operations on all the destinations hosted by a single JMS server, either programmatically with JMX or
by using the Administration Console. For more information see, Section 10.5,
Controlling Message Operations on Destinations.
Understanding JMS Resource Configuration 2-5
■
JMS servers can be undeployed and redeployed without having to reboot WebLogic Server.
For more information on configuring JMS servers, see Section 3.4, JMS Server
Configuration.
2.5 Overview of JMS Modules
