Oracle WebLogic Server 10.3.6.0 Documentation > Administration Console Online Help > Configure automatic migration of JMS services

Administration Console Online Help

Previous Next Open TOC in new window
Content starts here

Configure automatic migration of JMS services

Before you begin

Before you can configure JMS-related services to be automatically migrated to another server in the cluster, you must configure a migratable target for the service and its associated persistent store. See Configure migratable targets for JMS-related services.

For persistent messaging, you must configure a custom persistent store that is targeted to the same migratable target as the JMS service. Unless you are using pre/post migration scripts to move the store data across migrated servers, the custom store must be configured such that all the candidate servers in the migratable target have access to it. See Configure JMS-related services migration.


You can configure your JMS-related services to be automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services. For example, a JMS server, all of its destinations, and its associated persistent store will automatically move with their migratable target to a healthy server if the current hosting server should fail. JMS-related services include JMS servers, SAF agents, path service, and custom stores.

To configure the automatic migration of JMS-related services hosted by a migratable target:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).
  2. In the Domain Structure tree, expand Environment, and then select Clusters.
  3. On the Summary of Clusters page, select the cluster you want to modify.
  4. On the Configuration > Migration page, modify the Migration Basis field as follows:
    • Database -- requires that Data Source For Automatic Migration field is set with a valid JDBC system resource. It implies that there is a table created on that resource that migrating servers will use for leasing.
    • Consensus -- requires that all servers that are migratable, or which could host an auto-migratable target, have a Node Manager associated with them.
  5. Under Environment, select Migratable Targets.
  6. On the Summary of Migratable Targets page, select the migratable target you want to modify.
  7. Go to the Configuration > Migration page.
  8. Use the Service Migration Policy drop-down to select one of the following options:
    • Auto-Migrate Exactly-Once Services -- indicates that if at least one Managed Server in the candidate list is running, then the JMS service will be active somewhere in the cluster if servers should fail or are shut down (either gracefully or forcibly). For example, a migratable target hosting a path service should use this option so if its hosting server fails or is shut down, the path service will automatically migrate to another server and so will always be active in the cluster. Be aware that this value can lead to target grouping. For example, if you have five exactly-once migratable targets and only one server member is started, then all five migratable targets will be activated on that server member.
    • Auto-Migrate Failure Recovery Services -- indicates that the JMS service will only start if its UPS is started. If an administrator manually shuts down the UPS either gracefully or forcefully, this service will not be migrated. However, if the UPS fails due to an internal error, then this service will be migrated to another candidate server. If such a candidate server is unavailable (due to a manual shutdown or an internal failure), then the migration framework will first attempt to reactivate the service on its UPS server. If the UPS server is not available at that time, then the service will be migrated to another candidate server.
  9. Click Save to save your changes.
  10. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
    Not all changes take effect immediately—some require a restart (see Use the Change Center).

After you finish

You may want to migrate a JMS service back to the original primary server once it is back online. Unlike the JTA Transaction Recovery Service, JMS services do not automatically migrate back to the primary server when it becomes available, so you need to manually migrate these services. See Manually migrate JMS-related services.


Back to Top