The main steps for configuring a JMS server are:
- 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.
- Create JMS servers After creating a basic JMS server, you can define a number of optional properties:
- Configure general JMS server properties
- Configure JMS server thresholds and quota
- Configure JMS server message log rotation
- 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. 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.
- 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.
- Pause JMS server message operations on server restart
- Pause JMS server message operations at runtime
- 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.
- Create JMS session pools
- Create JMS connection consumers
- If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit .
- In the Administration Console, expand Services > Messaging and select JMS Servers.
- In the Summary of JMS Servers page, click New. Note: Once you create a JMS server, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
- On the Create a JMS Server page:
- In Name, enter a name for the JMS server.
- 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 New 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 custom persistent stores. 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.
- Click Next to proceed to the targeting page.
- On the Select Targets page, select the server instance or migratable server target on which to deploy the JMS 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. Note: In a clustered server environment, a recommended best practice is to target a 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 automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services.
- Click Finish.
- On the Summary of JMS Servers page, click the new JMS server to open it. Note that there are many optional parameters that can be set on the JMS server configuration tabs, including General configuration parameters, Thresholds and Quotas, Logging, and Server Session Pools.
- After modifying any values, click Save.
- To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Enter the Name and choose the persistent store.
Choose the soa_server1 (migratable option)
View Summary of Servers
Create JMS Server on Second Manages Server (Migratable)
Summary of JMS Server shows new JMS Server