org.apache.ignite.compute

## Interface ComputeJob

All Superinterfaces:
  Serializable

All Known Subinterfaces:
  PlatformJob

All Known Implementing Classes:
  CollectConflictPartitionKeysTask.CollectPartitionEntryHashesJob, ComputeJobAdapter, ComputeJobContinuationAdapter, GridCacheAdapter.TopologyVersionAwareJob, GridClosureProcessor.C1, GridClosureProcessor.C1MLA, GridClosureProcessor.C2, GridClosureProcessor.C2MLA, GridClosureProcessor.C4, GridClosureProcessor.C4MLA, GridDistributedCacheAdapter.GlobalRemoveAllJob, GridifyJobAdapter, PlatformAbstractJob, PlatformClosureJob, PlatformFullJob, RetrieveConflictPartitionValuesTask.RetrieveConflictValuesJob, VisorCacheConfigurationCollectorJob, VisorCacheGroupEncryptionTask.VisorReencryptionBaseJob, VisorJob, VisorNodeConfigurationCollectorJob, VisorNodeDataCollectorJob, VisorNodeEventsCollectorTask.VisorNodeEventsCollectorJob

    public interface ComputeJob
    extends Serializable

Defines executable unit for `ComputeTask`.

# Description

Grid job is an executable unit of `ComputeTask`. Grid task gets split into jobs when `ComputeTask.map(List, Object)` method is called. This method returns all jobs for the task mapped to their corresponding grid nodes for execution. Grid will then serialize this jobs and send them to requested nodes for execution. When a node receives a request to execute a job, the following sequence of events takes place:

1. If collision SPI is defined, then job gets put on waiting list which is passed to underlying `CollisionSpi` SPI. Otherwise job will be submitted to the executor service responsible for job execution immediately upon arrival.
2. If collision SPI is configured, then it will decide one of the following scheduling policies:
   - Job will be kept on waiting list. In this case, job will not get a chance to execute until next time the Collision SPI is called.
   - Job will be moved to active list. In this case system will proceed with job execution.
   - Job will be rejected. In this case the `ComputeJobResult` passed into `ComputeTask.result(ComputeJobResult, List)` method will contain `ComputeExecutionRejectedException` exception. If you are using any of the task adapters shipped with Ignite, then job will be failed over automatically for execution on another node.
3. For activated jobs, an instance of distributed task session (see `ComputeTaskSession`) will be injected.
4. System will execute the job by calling `execute()` method.
5. If job gets cancelled while executing then `cancel()` method will be called. Note that just like with `Thread.interrupt()` method, grid job cancellation serves as a hint that a job should stop executing or exhibit some other user defined behavior. Generally it is up to a job to decide whether it wants to react to cancellation or ignore it. Job cancellation can happen for several reasons:
   - Collision SPI cancelled an active job.
   - Parent task has completed without waiting for this job's result.
   - User cancelled task by calling `IgniteFuture.cancel()` method.
6. Once job execution is complete, the return value will be sent back to parent task and will be passed into `ComputeTask.result(ComputeJobResult, List)` method via `ComputeJobResult` instance. If job execution resulted in a checked exception, then `ComputeJobResult.getException()` method will contain that exception. If job execution threw a runtime exception or error, then it will be wrapped into `ComputeUserUndeclaredException` exception.

# Resource Injection

Grid job implementation can be injected using IoC (dependency injection) with ignite resources. Both, field and method based injection are supported. The following ignite resources can be injected:

- `TaskSessionResource`
- `JobContextResource`
- `IgniteInstanceResource`
- `LoggerResource`
- `SpringApplicationContextResource`
- `SpringResource`

Refer to corresponding resource documentation for more information.

# ComputeJobAdapter

Ignite comes with convenience `ComputeJobAdapter` adapter that provides default empty implementation for `cancel()` method and also allows user to set and get job argument, if there is one.

# Distributed Session Attributes

Jobs can communicate with parent task and with other job siblings from the same task by setting session attributes (see `ComputeTaskSession`). Other jobs can wait for an attribute to be set either synchronously or asynchronously. Such functionality allows jobs to synchronize their execution with other jobs at any point and can be useful when other jobs within task need to be made aware of certain event or state change that occurred during job execution.

Distributed task session can be injected into `ComputeJob` implementation using `@TaskSessionResource` annotation. Both, field and method based injections are supported. Refer to `ComputeTaskSession` documentation for more information on session functionality.

# Saving Checkpoints

Long running jobs may wish to save intermediate checkpoints to protect themselves from failures. There are three checkpoint management methods:

- `ComputeTaskSession.saveCheckpoint(String, Object, ComputeTaskSessionScope, long)`
- `ComputeTaskSession.loadCheckpoint(String)`
- `ComputeTaskSession.removeCheckpoint(String)`

Jobs that utilize checkpoint functionality should attempt to load a check point at the beginning of execution. If a `non-null` value is returned, then job can continue from where it failed last time, otherwise it would start from scratch. Throughout it's execution job should periodically save its intermediate state to avoid starting from scratch in case of a failure.

### Method Summary

All Methods Instance Methods Abstract Methods
`void` `cancel()` This method is called when system detects that completion of this job can no longer alter the overall outcome (for example, when parent task has already reduced the results).
`Object` `execute()` Executes this job.

### Method Detail

#### cancel

    void cancel()

This method is called when system detects that completion of this job can no longer alter the overall outcome (for example, when parent task has already reduced the results). Job is also cancelled when `IgniteFuture.cancel()` is called.

Note that job cancellation is only a hint, and just like with `Thread.interrupt()` method, it is really up to the actual job instance to gracefully finish execution and exit.

#### execute

    Object execute()
            throws IgniteException

Executes this job.

Returns:
  Job execution result (possibly `null`). This result will be returned in `ComputeJobResult.getData()` method passed into `ComputeTask.result(ComputeJobResult, List)` task method on caller node.
Throws:
  `IgniteException` - If job execution caused an exception. This exception will be returned in `ComputeJobResult.getException()` method passed into `ComputeTask.result(ComputeJobResult, List)` task method on caller node. If execution produces a `RuntimeException` or `Error`, then it will be wrapped into `IgniteCheckedException`.

${current.year} Copyright © Apache Software Foundation

Follow @ApacheIgnite

Ignite Database and Caching Platform | : ver. 2.11.0
Release Date | : September 11 2021