JMS servers are environment-related configuration entities that act as management containers for the queues and topics in JMS modules that are targeted to them. A JMS server's primary responsibility for its destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. JMS servers also manage message paging on destinations, and, optionally, can manage message and/or byte thresholds, as well as server-level quota for its targeted destinations. As a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all the destinations that it hosts.
Note: User-defined stores can be configured before creating a JMS server or they can be configured on the fly as part of the JMS server configuration process.
After creating a basic JMS server, you can define a number of optional properties:
Optional general JMS server properties include selecting a user-defined persistent store, changing message paging defaults, specifying a template to use when your applications create temporary destinations, and specifying expired message scanning parameters.
Define upper and lower byte and message thresholds for destinations in JMS modules targeted to this JMS server, specifying a maximum size allowed for messages and the number of messages and/or bytes available to a JMS server, and selecting 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.
Define message logging properties, such as changing the default name of its log file, as well as configuring criteria for moving (rotating) old log messages to a separate file. A JMS server's log file contains the basic events that a JMS message traverses through, such as message production, consumption, and removal.
Note: In a clustered server environment, a recommended best practice is to target the JMS server to a migratable target, so that a member server will not be a single point of failure. A JMS server can also be configured to automatically migrate from an unhealthy server instance to a healthy server instance, with the help of the WLS health monitoring services. See Configure migratable targets for JMS-related services.
Note: JMS session pool and connection consumer configuration objects were deprecated in release 9.0 of WebLogic Server. They are not a required part of the J2EE specification, do not support JTA user transactions, and are largely superseded by message-driven beans (MDBs), which are a required part of J2EE.