Configuring Oracle Enterprise Scheduler

You can run Oracle Enterprise Scheduler as a single instance or as a cluster of servers. Each Oracle Enterprise Scheduler server includes a request processor and dispatcher, both of which must be configured.

Configuring Oracle Enterprise Scheduler involves the following main steps:

  1. Configure a cluster. Optionally, configure a cluster of Oracle Enterprise Scheduler servers.

  2. Configure the request processor. Configure the Oracle Enterprise Scheduler component which receives and manages job requests.

  3. Configure the request dispatcher. Configure the Oracle Enterprise Scheduler component that polls the request processor for job requests and dispatches jobs.

This section contains the following topics:

Expanding an Oracle Enterprise Scheduler Cluster

An Oracle Enterprise Scheduler cluster is created when the WebLogic domain is created. You may want to expand the cluster to handle a larger load. You can add new cluster nodes to an Oracle Enterprise Scheduler cluster from the Oracle WebLogic Server Console.

When scaling out an Oracle Enterprise Scheduler cluster with an additional managed server, it may be undesirable for the new server to immediately begin processing requests in the default work assignment. This could be the case if all other servers have work assignments bound in standard mode. If one or more of the running servers is using the default work assignment, however, then the present work allocation is compatible with a server using the default work assignment.

When you add a new server to an existing cluster, it may be undesirable for the new server to immediately start processing requests in the default work assignment. This could be the case if all other servers have work assignments bound in standard mode. If at least one of the running servers uses the default work assignment, this implies that the present work allocation is compatible with a server using the default work assignment.

Oracle Enterprise Scheduler provides protection for a new server so the user has an opportunity to perform work allocation before the server starts processing jobs. When a newly created server starts for the first time, Oracle Enterprise Scheduler determines whether using the default work assignment could be problematic and if so, binds a pre-seeded internal work assignment (ESSInternalWA) which includes a health check job. The user can use the health check job to check the server, and then unbind the internal work assignment and bind a user-created work assignment as needed.

Note that when determining if the default work assignment can be used, Oracle Enterprise Scheduler considers all running servers in the group and it is irrelevant what applications are deployed to the servers. Servers that are down are not taken into account.

For more information about work assignments, see Managing Work Assignments.

For more information about expanding a cluster using Oracle WebLogic Server Console, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

Configuring a Request Processor

If no work assignment bound to a request processor, the default work assignment processes job requests. The binding of work assignments provides control over what jobs run at what times and with what resources. A binding can be made in one of two modes: standard (the default) or exclusive.

Standard binding mode means the request processor can process job requests as defined by the specialization rules when an active workshift is defined. If a job request is specialized to two different work assignments, either of those work assignments or the default work assignment can process the job request.

When using exclusive binding mode, job requests specialized to the work assignment are processed exclusively by that work assignment when it is active. These job requests are excluded from all other work assignments, including the default work assignment. If the work assignment does not have an active workshift, then the job request can be processed by another work assignment.

As an example, consider the following work assignments:

  • LongWA, specialization is (definition = 'JobDefinition://mypackage/LongRunningJob')

  • SamWA, specialization is (definition = 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam')

Suppose both LongWA and SamWA are bound in standard mode. When Sam submits LongRunningJob, either LongWA or SamWA can process the request.

Suppose LongWA is bound in standard mode and SamWA is bound in exclusive mode. When Sam submits LongRunningJob, only SamWA can process the request. The exclusive binding causes the specialization for LongWA to act as if it is:

(definition = 'JobDefinition://mypackage/LongRunningJob') AND NOT (definition 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam')

which is effectively:

(definition = 'JobDefinition://mypackage/LongRunningJob') AND NOT (user = 'sam')

Note:

Be careful about using the exclusive binding mode when your specializations overlap. For example, if you bind both LongWA and SamWA in exclusive mode, then SamWA cannot run LongRunningJob at all. In this case, the specialization for SamWA becomes:

(definition = 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam') AND NOT (definition = 'JobDefinition://mypackage/LongRunningJob')

Requirements for binding a work assignment are as follows:

  1. The work assignment must be enabled, meaning its active flag must be set.

  2. The work assignment must have at least one workshift.

  3. Each workshift in the work assignment must have a thread allocation of at least one.

  4. If the workshift includes a schedule, the following must be true:

    • The schedule must be active, meaning it is not expired.

    • The workshift duration must be at least one.

  5. A work assignment can be bound to a particular server at most one time.

  6. A work assignment can be bound to any number of servers in the group, but all bindings must use the same mode. Within a group, a work assignment cannot be bound in standard mode on one server and exclusive mode on another server.

For more information about work assignments, see Managing Work Assignments.

To configure a request processor:

  1. From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
  2. From the Scheduling Services menu, select Request Processor and then select Configure.
  3. Under the Enable Request Processor field, enable or disable the request processor. Select the Enable Request Processor check box to turn on request processing.
  4. Optionally, under the Work Assignment Bindings section, bind a work assignment to the request processor.

    • Add: To bind a work assignment to the request processor, click Add.

      From the Select Work Assignment popup window, select a work assignment from the list and click OK.

    • Remove: To delete a work assignment binding from the job request processor, select a work assignment from the list of bindings and click Remove.

    • Exclusive Binding: Select to bind a work assignment exclusively to the request processor. The binding applies even if the work assignment is not enabled in the work assignment definition, or if the server is down. If a work assignment is bound to multiple servers, all the servers to which it is bound must use the same binding mode.

  5. Optionally, under the Advanced Configuration section, configure the number of threads and the starvation threshold in minutes.

    • Thread Count: In the text field, enter the number of threads you want the processor to handle.

    • Starvation threshold (min): In the text field, enter the starvation threshold in minutes. The starvation threshold specifies the wait time for job requests.

  6. Click Apply to save your changes.

Configuring a Request Dispatcher

Use the Configure Request Dispatcher page to enable or disable the job request dispatcher. You can also configure the polling interval for the request dispatcher.

Requests remain in waiting state in the Oracle Enterprise Scheduler repository, until the request dispatcher polls the repository for requests that are ready to run. After polling the repository, the dispatcher sets all requests to ready state. The request processor takes over control of the job requests after they have been placed in ready state.

The default maximum polling interval is 15 seconds.

To configure a request dispatcher:

  1. From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
  2. From the Scheduling Services menu, select Request Dispatcher and then select Configure.
  3. Under the Enable Request Dispatcher field, enable or disable the request processor.

    Select the Enable Request Dispatcher check box to turn on request dispatching.

  4. Optionally, under the Advanced Configuration section, configure the polling interval for the request dispatcher. In the Maximum Poll Interval field, enter the minimum interval at which the dispatcher polls for requests.
  5. Click Apply to save your changes.