Job Life Cycle Statuses: Additional Information

Resuming a Job

It is possible to resume a job (resume()). This is called on by the job async executor and resources. The executors provide this method in the event that a job has timed out and won’t respond. Alternatively, the job will fail.

Note: please contact the Ooyala Flex team for more information regarding this.

Retrying a Job

Jobs can be retried (retry()). This is called on by the job sync, async executors, and resources in the event that Enterprise has retried the job. Job executors may decide to run the execute()method immediately. It is important to consider different scenarios before executing the job.

Note: please contact the Ooyala Flex team for more information regarding this.


JEF includes a locking system that works in both distributed and multi-phase execution contexts.

Redis is used as a shared repository to manage locking. A single library component (flex-lockserviceprovider-library) has been defined. This library has the following responsibilities:

1) It acquires the lock.

2) Registers to be notified when the lock is available.

3) Releases the lock.

4) Listens to the callback so that it knows when the lock becomes available.

Lock requirements for jobs are optional configurations that are defined in the ActionConfiguration. Locks can be: SHARED, EXCLUSIVE, or NONE.

JEF processes lock requirements internally through the Job Engine service. If a lock is not available, a job is put in a WAITING_FOR_LOCK state, until the lock is released.

Jobs can be released through the Job Engine (in the case of synchronous jobs) or automatically through the job async executor.

Note: This is done automatically. No action is required by the developer.
Note: Lock libraries can also be used for custom purposes. Please contact the Ooyala Flex team if you require low level lock access.


As a user you can cancel a job using either the UI or REST API.

In a distributed environment with no available transaction options, you will need a way to cancel jobs. This is especially important when a job is not found in the architecture.

In the case of JEF, Redis is used as a shared repository in order to mark jobs that are being cancelled. The Cancel service is available in the flex-executioncommons-library.

It is possible to cancel a job while it is in a QUEUED state in JEF. It is also possible to cancel a job whilst using a job async executor when executing a job.

cancel(): The cancel()method is called on by the job async executor and resources if Enterprise has requested to cancel the job. The job executor might decide to ignore or not implement this interface. If so, the job can’t be cancelled.

Note: Currently JEF uses ActionProgressService notifications to check if there is a cancel request pending for a job. If there is a cancel request, the cancel()method is invoked for that executor. It is the responsibility of the executor to verify that the job ID corresponds to the execution job ID.