Configure migratable targets for JMS-related services

Before you begin

Note: Oracle recommends configuring high availability using cluster targeted JMS servers that share same cluster target with a custom store. The legacy migratable targets feature is not supported in partitions, resource groups, or resource group templates. See Configure JMS services for migration and high availability.

Before you can configure JMS-related services to automatically migrate to another server in the cluster, you must configure the managed servers in the cluster for migration, including assigning managed servers to a machine and configuring Node Manager. See Configure JMS-related services migration using migratable targets.

A migratable target is a special target that serves as a grouping of services, such as such as JMS servers, SAF agents, path service, or custom stores, and which is active on only server member in a cluster. High availability is achieved by migrating a migratable target from one server member to another when a problem occurs on the original server, either manually or automatically, based on server health monitoring capabilities. For automatic migration, you need to select the appropriate automatic migration policy. You can also optionally provide pre/post-migration scripts to move a persistent store's data across migrated servers. There are also options to have a migratable target with a failed service deactivated and reactivated in place, instead of being migrated.

To configure the migratable target servers for JMS-related service migration:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).
In the Domain Structure tree, expand Environment, then select Migratable Targets.
On the Summary of Migratable Targets page, click New.
On the Create a new Migratable Target page:
1. In Name, enter a name for the migratable target.
2. In Cluster, select a configured cluster for the migratable target.
3. Click Next.
On the Migratable Target Properties page:
a. In User Preferred Server Name, select the server in the cluster that you want to associate the migratable target with.

b. In Service Migration Policy, select the automatic migration policy that you want to use:
- Manual Service Migration Only -- the default for manually migrating JMS services.
- 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. Note 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.
c. Click Finish.

For more information on auto-migrating JMS services, see Configure automatic migration of JMS services using migratable targets.
On the Summary of Migratable Targets page, select the migratable target created in steps 4 and 5.
On the Migratable Target > Configuration > Migration page, update any additional parameters as required:
- Constrained Candidate Servers -- select the servers you want to use as a JMS server backup and move them to the Chosen list. The servers you select must have access to the current service's custom store, which must also be targeted to the same migratable target as the migratable JMS service. Either that, or you must use the following fields to define migration pre/post migration scripts to move the store's data to the target backup server.
- Pre-Migration Script Path -- the path to the pre-migration script to run before a migratable target is actually activated.
- Post-Migration Script Path -- the path to the post-migration script to run after a migratable target is fully deactivated.
- Post-Migration Script Failure Cancels Automatic Migration -- specifies whether or not a failure during execution of the post-deactivation script is fatal to the migration.
- Allow Post-Migration Script To Run On a Different Machine -- specifies whether or not the post-deactivation script is allowed to run on a different machine.
- Restart On Failure -- specifies whether or not a failed service will first be deactivated and reactivated in place, instead of being migrated.
- Seconds Between Restarts -- specifies how many seconds to wait in between attempts to restart the failed service.
- Number Of Restart Attempts -- specifies how many restart attempts to make before migrating the failed service.
Note: The pre/post-migration scripts must be located in the MIDDLEWARE_HOME/user_projects/domains/mydomain/bin/service_migration directory, where mydomain is a domain-specific directory, with the same name as the domain. For your convenience, sample pre/post-migrations scripts are provided in this directory.

For more information about these fields, refer to Configuration Options.
Click Save to save your changes.
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).

Administration Console Online Help

Configure migratable targets for JMS-related services