Weblogic 10.3.5: Configure JMS Servers on Weblogic Cluster

 Configure JMS servers Weblogic Cluster

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:
   
   • Configure general JMS server 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.
   
   • Configure JMS server thresholds and quota
   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.
   
   • Configure JMS server message log rotation
   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.   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.
   • Pause JMS server message operations on server restart 
   • Pause JMS server message operations at runtime  


2. 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
   To create a JMS server
   
   
   1.  If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit .
   2. In the Administration Console, expand Services > Messaging and select JMS Servers.
   3. 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.
      
   4. On the Create a JMS Server page:
      1. In Name, enter a name for the JMS server.
      2. 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.
         
      3. Click Next to proceed to the targeting page.
   5. 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.
      
   6. Click Finish.
   7. 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.
      
   8. After modifying any values, click Save.
   9. 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)
   
   
   
   
   

Enter the Name and The Persistent Store different than the first JMS Server



Summary of JMS Server shows new JMS Server