Defines compute grid functionality for executing tasks and closures over nodes
in the
GridProjection. Instance of
GridCompute is obtained from grid projection
as follows:
GridCompute c = GridGain.grid().compute();
The methods are grouped as follows:
-
apply(...) methods execute
GridClosure jobs over nodes in the projection.
-
call(...) methods execute
Callable jobs over nodes in the projection.
Use
GridCallable for better performance as it implements
Serializable.
-
run(...) methods execute
Runnable jobs over nodes in the projection.
Use
GridRunnable for better performance as it implements
Serializable.
-
broadcast(...) methods broadcast jobs to all nodes in the projection.
-
affinity(...) methods colocate jobs with nodes on which a specified key is cached.
Note that if attempt is made to execute a computation over an empty projection (i.e. projection that does
not have any alive nodes), then
GridEmptyProjectionException will be thrown out of result future.
Serializable
Also note that
Runnable and
Callable implementations must support serialization as required
by the configured marshaller. For example,
GridOptimizedMarshaller requires
Serializableobjects by default, but can be configured not to. Generally speaking objects that implement
Serializableor
Externalizable will perform better. For
Runnable and
Callable interfaces
GridGain provides analogous
GridRunnable and
GridCallable classes which are
Serializable and should be used to run computations on the grid.
Load Balancing
In all cases other than
broadcast(...), GridGain must select a node for a computation
to be executed. The node will be selected based on the underlying
GridLoadBalancingSpi,
which by default sequentially picks next available node from grid projection. Other load balancing
policies, such as
random or
adaptive, can be configured as well by selecting
a different load balancing SPI in grid configuration. If your logic requires some custom
load balancing behavior, consider implementing
GridComputeTask directly.
Fault Tolerance
GridGain guarantees that as long as there is at least one grid node standing, every job will be
executed. Jobs will automatically failover to another node if a remote node crashed
or has rejected execution due to lack of resources. By default, in case of failover, next
load balanced node will be picked for job execution. Also jobs will never be re-routed to the
nodes they have failed on. This behavior can be changed by configuring any of the existing or a custom
GridFailoverSpi in grid configuration.
Resource Injection
All compute jobs, including closures, runnables, callables, and tasks can be injected with
grid resources. Both, field and method based injections are supported. The following grid
resources can be injected:
-
GridTaskSessionResource
-
GridInstanceResource
-
GridLoggerResource
-
GridHomeResource
-
GridExecutorServiceResource
-
GridLocalNodeIdResource
-
GridMBeanServerResource
-
GridMarshallerResource
-
GridSpringApplicationContextResource
-
GridSpringResource
Refer to corresponding resource documentation for more information.
Here is an example of how to inject instance of
Grid into a computation:
public class MyGridJob extends GridRunnable {
...
@GridInstanceResource
private Grid grid;
...
}
Computation SPIs
Note that regardless of which method is used for executing computations, all relevant SPI implementations
configured for this grid instance will be used (i.e. failover, load balancing, collision resolution,
checkpoints, etc.). If you need to override configured defaults, you should use compute task together with
GridComputeTaskSpis annotation. Refer to
GridComputeTask documentation for more information.