• Description
• Job Context Injection
• Utilizing Job Context For Fail-Over

Description

GridJobContext ^Javadoc is attached to every job executed on the grid. Note that unlike Distributed Grid Task Session, which distributes all attributes to all jobs in the task including the task itself, job context attributes belong to a job and do not get sent over network unless a job moves from one node to another.

In most cases a job, once assigned to a node, will never move to another node. However, it is possible that Collision SPI rejects a job before it ever got a chance to execute (job rejection) which will cause fail-over to another node. Or user is not satisfied with the outcome of a job and fails it over to another node by returning GridJobResultPolicy.FAILOVER from GridTask.result(GridJobResult, List<GridJobResult>) method. In this case all context attributes set on one node will be available on any other node this job travels to.

You can also use GridJobContext to communicate between SPI's and jobs. For example, if you need to cancel an actively running job from Collision SPI, you may choose to set some context attribute on the job to mark the fact that a job was canceled by grid and not by a user. Context attributes can also be assigned in Failover SPI prior to failing over a job.

From within GridTask.result(GridJobResult, List<GridJobResult>) or GridTask.reduce(List<GridJobResult>) methods, job context is available via GridJobResult.getJobContext() method which gives user the ability to check context attributes from within grid task implementation for every job returned from remote nodes.

Attribute names that start with "gridgain:" are reserved for internal system use.

Job Context Injection

GridJobContext can be injected into GridJobs. See Resources Injection page for additional injection details.

Utilizing Job Context For Fail-Over

You can utilize GridJobContext for efficient fail-over as well. For example, if you have a long running job, then you can store intermediate results into GridJobContext. Then if you feel that the job would have a better chance to complete on another, more efficient node, you can finish your job execution preemptively by returning some code from GridJob.execute() method. On the task side you will fail this job over to another node by properly overriding GridTask.result(..) method and checking for the proper return code.

Whenever your job arrives to another node, you can check if there is any intermediate state stored in GridJobContext and, if it is, you can start your job from that state instead of starting it from scratch.