Job Life Cycle Statuses

The diagram below shows the possible statuses during the life cycle of a job. These are returned by the action executor as the workflow progresses:

Running

JEF executors set this status to appear when the action configuration instance is processed by the action executor.

Note: Developers could send progress updates. ( For more information please see ActionExecutorUpdate example in the flex-jefexampleexecutor-service in BitBucket.

Example:

{"executionId":"624","workflowId":null,"progress":25,"message":"In Progress","status":"RUNNING"}

Completed

When the execute method completes, it returns an instance of the ActionExecutorResponse and Ooyala Flex either progresses to the next stage in the workflow, or finishes the workflow.

In the response, you can set any of the following fields:

  • result: this is a message that shows in the Recent Activity panel in the Ooyala Flex UI. You can customise the message if required.
  • executionId: This is an identifier for the job. This enables you to retrieve information about the job at later stages.
  • jobContextVariables: This contains a map of key values which are reflected under the Variables tab in the Ooyala Flex UI. These are passed to the next stage of the workflow.
  • workflowContextVariables: This is essentially the same as the jobContextVariables, however it overrides the workflow context.

When the action executor has finished processing, the status is automatically updated to “Completed”.

Example:

{"executionId":"624","workflowId":null,"progress":100,"message":"Success","status":"COMPLETED"}

Failed

If an unhandled exception is thrown within the ActionExecutor.execute method, the job and/or workflow that instances the job will fail. Job and workflow failures can be seen in the Recent Activity panel in the Ooyala Flex UI.

Example:

{"executionId":"624","workflowId":null,"progress":100,"message":"Success","status":"FAILED"}

Queued

If the request has been handled, but it has not started yet, it will be in a QUEUED state. Jobs are put in a QUEUED state from the point they are delivered from Enterprise, until the execute class starts execution.

Example:

{"executionId":"624","workflowId":null,"progress":0,"message":"Success","status":"QUEUED"}

Cancelled

This status is displayed if a cancellation occurs. A cancellation can occur if a job is cancelled by the job, workflow, or by the underlying services. This is internally managed by JEF, and so, no action is required by the developer.

Example:

{"executionId":"624","workflowId":null,"progress":0,"message":"Success","status":"Cancelled"}

Timed Out

Async executors can see jobs timing out. Jobs that are running in async executors are watchers for notification updates. If long running do not update, they are marked as TIMED_OUT by the watchers or upon restarting the service. This is reported to Enterprise but the job will not be in a FAILED state.

Waiting For Lock

JEF requests are processed internally (through the Job Engine service) for available locks if SHARED or EXCLUSIVE locks are required. If a lock is not available (because another job is currently using it in Enterprise or a JEF execution), the job remains in a WAITING_FOR_LOCK state until the required job is available and the execution can proceed further.

https://help.ooyala.com/sites/all/libraries/dita/en/media-logistics/flex/dev/70/jef_programming_guide_job_life_cycle_states.html

Was this article helpful?