OTN Home > Oracle WebLogic Server 10.3.4.0 Documentation > Administration Console Online Help > Configure JMS servers

Administration Console Online Help

Previous Next Open TOC in new window
Content starts here

Configure JMS servers


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.

The main steps for configuring a JMS server are:

  1. For storing persistent messages, you can simply use the host server's default persistent file store, which requires no configuration on your part. However, you can also create a dedicated file-based store or JDBC store for JMS.

    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.

    • Create file stores. A file store maintains subsystem data, such as persistent JMS messages and durable subscribers, in a group of files in a directory.
    • Create JDBC stores. A JDBC store maintains subsystem data, such as persistent JMS messages and durable subscribers, in a database.
  2. Create JMS servers

    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.

  3. If you skipped the targeting step when you created a JMS server, or want to modify the current targeting parameters, you can do so at anytime. You can target a JMS server to a different standalone WebLogic Server instance or migratable target server. Migratable targets define a set of WebLogic Server instances in a cluster that can potentially host a pinned service, such as a JMS server. See Change JMS server targets.

    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.

  4. In the event that you need to troubleshoot destinations targeted to a JMS server, you can temporarily pause all message production, insertion (in-flight messages), and consumption operations on all such destinations. Destinations can be paused either on a server restart or at runtime.
  5. Optionally, create JMS Session Pools, which enable your applications to process messages concurrently, and Connection Consumers (queues or topics) that retrieve server sessions and process messages.

    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.

    1. Create JMS session pools
    2. Create JMS connection consumers

Related Tasks

Related Topics


Back to Top