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:
Configure a cluster. Optionally, configure a cluster of Oracle Enterprise Scheduler servers.
Configure the request processor. Configure the Oracle Enterprise Scheduler component which receives and manages job requests.
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:
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.
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:
The work assignment must be enabled, meaning its active flag must be set.
The work assignment must have at least one workshift.
Each workshift in the work assignment must have a thread allocation of at least one.
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.
A work assignment can be bound to a particular server at most one time.
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:
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: