4 High Availability

This chapter describes the issues related to Oracle Fusion Middleware high availability.

The following topics are covered in this chapter:

4.1 Issues Related to Automatic Service Migration

This section contains the following topic:

4.1.1 Oracle User Messaging Service 12c (12.1.3) Does Not Support Automatic Service Migration

In enterprise deployments that take advantage of high availability, Oracle recommends that you configure Oracle BAM to use Automatic Service Migration, which migrates specific services to a different Managed Server in the cluster when a server fails.

However, in some scenarios where Oracle BAM is producing constant and intensive User Messaging Service (UMS) messages, a Managed Server failure might leave some alert messages stuck in the UMS queues. This is because UMS 12c (12.1.3) does not currently support Automatic Service Migration.

To workaround this issue, you can recover messages in the UMS queues by restarting the failed Oracle BAM Managed Server. To resume the appropriate capacity and load sustainability after a BAM server failure, you must do two things:

  • Restart the failed Managed Server.

  • Fail back the migrated services to the original Managed Server.

For more information, see Failing Back Oracle BAM Services After Automatic Service Migration Occurs in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.

If a BAM server restart is not compatible with your system's recovery time objectives (RTO), then you can configure UMS with Advanced Queuing (AQ) JMS instead of the default JMS provider. For more information, see Appendix B, Configuring User Messaging Service with AQ JMS, in Oracle Fusion Middleware Administering Oracle User Messaging Service.

4.2 Issues Pertaining to Oracle BAM

This section contains the following topic:

4.2.1 Configuring Oracle BAM After Scale Up

Oracle BAM requires additional configuration steps after you configure the domain. See the topic Configuring BAM for High Availability in the 12.1.3 version of the Oracle Fusion Middleware High Availability Guide.

4.3 DELETED for PS3– Issues Pertaining to Cross Component Wiring

This topic includes the following issue:

4.3.1 DELETED for PS3:SOA Managed Servers Not Updated (Cross Component Wiring)

When you add or remove Managed Servers to a cluster and ESS and WSMPM provide services to SOA and publish their services to the service table, SOA Managed Servers do not receive these updates in a cross component wiring setup unless you force a bind.

To workaround this issue, you must force your cross component wiring setup to get the complete list of cluster members.
To use the cluster_name syntax with WSMPM:
  1. Log into Fusion Middleware Control.
  2. Select Cross Component Wiring-Service Tables from the WebLogic Domain drop down menu.
  3. Select the OWSM Policy Manager url:oracle:fmw.owsm-pm:t3 row then click Edit.
  4. Update the t3 and t3s values with the cluster name syntax t3://clustername, for example, t3://WSM-PM_Cluster. Click OK.
  5. Select Cross Component Wiring — Components from the WebLogic Domain drop down menu.
  6. SelectOWSM Agent.
  7. In Client configurations, select the row owsm-pm-connection-t3 and click Bind.
  8. Click OK.

4.3.2 DELETED for PS3: 503 HTTP Error for POST Requests During Scale Down or Failover

Oracle Service Bus and SOA use web service invocations that in turn use the HTTP request method POST.

If a POST request is sent to a WebLogic server that is shutting down (for example, during scale down or failover) and the WebLogic server can’t complete the request, the load balancer (Oracle HTTP Server or Oracle Traffic Director) returns the error HTTP Error 503 — Service Unavailable to the invoker. This error message is expected because POST requests don’t cache nor idempotent.