Configuring Automatic Engine Recovery for Oracle BPEL Process Manager

Configuring Automatic Engine Recovery for Oracle BPEL Process Manager

Oracle SOA Suite provides an automatic recovery feature in Oracle Enterprise Manager Fusion Middleware Control Console that enables you to configure and recover:

  • All activities (for example, wait activities and OnAlarm branches of pick activities) that have an associated expiration date and are scheduled with the SOA Infrastructure to be rescheduled
  • All activities that are not complete over a provided threshold time
  • All invoke and callback messages that are unresolved

Engine Recovery

To configure automatic recovery:

  • In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.
  • Click More BPEL Configuration Properties.
  • In the Name column, click RecoveryConfig.
  • Expand RecurringScheduleConfig.

This section enables you to configure recurring recovery attempts.

  • Set the following properties to values appropriate to your environment, and click Apply.
  • Property Description
    maxMessageRaiseSize The maximum number of messages to submit for each recurring recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

    The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A 0 value causes no messages to be selected from the database (effectively disabling recovery).

    startWindowTime The start time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:009:00).

    The default value is midnight (00:00). Any invalid parsed time value is defaulted to midnight.

    stopWindowTime The stop time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:009:00).

    If you do not want daily recovery, set the start and stop window times to be the same value. If the stop window time is earlier than the start window time, both the start and stop window times are changed to their respective default values.

    The default value is midnight (04:00), effectively setting recurring recovery to run until 04:00.

    Any invalid parsed time values default to 00:00.

    subsequentTriggerDelay The number of seconds between recovery attempts during daily recurring startup recovery periods. If the next recovery trigger falls outside of the current recovery period, that trigger is not scheduled until the next recurring recovery period (tomorrow).

    The default value is 300 (five minutes). A negative value causes the default to be selected.

    threshHoldTimeInMinutes This is the threshold time in minutes to ignore for automatic recovery processing. For automatic invoke and callback recovery, this value is used for picking messages with a received date less than the threshhold time.

    For automatic activities recovery, this value is used for picking activities with a modification date less than the threshhold time.

    This property prevents the message contention scenario in which a BPEL process service engine picks up a message for recovery while another thread on the service engine is in the middle of processing the message. This property ensures that the recovery part of the service engine only attempts recovery on messages older than the value for threshHoldTimeInMinutes.

    The default value is 10 minutes. A negative value causes the default to be selected.

  • Expand StartupScheduleConfig.

This section enables you to configure server startup recovery attempts.

  • Set the following properties to values appropriate to your environment, and click Apply.
Property Description
maxMessageRaiseSize The maximum number of messages to submit for each startup recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A zero value causes no messages to be selected from the database (effectively disabling recovery).

startupRecoveryDuration Specifies the number of seconds that the startup recovery period lasts. After the server starts, it goes into a startup recovery period. During this period, pending activities and undelivered callback and invocation messages are resubmitted for processing.

The default value is 600 (ten minutes). A negative or zero value disables startup recovery.

subsequentTriggerDelay The number of seconds between recovery attempts during the server startup recovery period. If the next recovery trigger falls outside the server startup period, that trigger is not scheduled and the server moves into the recurring recovery period.

The default value is 300 (five minutes). A negative value causes the default to be selected.

Note:

In a cluster, it is possible for different nodes to concurrently attempt an automatic recovery of the same items. The first node to lock the item attempts the recovery, while other nodes may raise an exception that can be safely ignored.

One Response so far.

  1. t says:

    thanks for sharing this