• Package
• Built-in Implementations
• Description
  • Job Rejection
  • Job Cancellation
  • GridCollisionExternalListener
• Configuration
  • Default Implementation

Click on ^Javadoc link to open Javadoc documentation.

Package

org.gridgain.grid.spi.collision ^Javadoc

Built-in Implementations

GridGain comes with following implementations for collision resolution that cover most popular strategies:

• GridFifoQueueCollisionSpi
• GridJobStealingCollisionSpi
• GridPriorityQueueCollisionSpi

Description

GridCollisionSpi ^Javadoc SPI allows to regulate how grid jobs get executed when they arrive on a destination node for execution. In general a grid node will have multiple jobs arriving to it for execution and potentially multiple jobs that are already executing or waiting for execution on it. There are multiple possible strategies dealing with this situation:

1. All jobs can proceed in parallel.
2. Jobs can be sequenced i.e., only one job can execute in any given point of time.
3. Only certain number or types of grid jobs can proceed in parallel.
4. Job may proceed based on some time based events.

Every time a new job arrives, it gets placed on waiting queue and it is up to Collision SPI to either reject or activate an waiting job, or cancel an active job, or do nothing. Generally, Collision SPI gets invoked in the following cases:

• A new job has arrived.
• An existing job has finished.
• A node metrics update has been received.
• Collision SPI implementation has called GridCollisionExternalListener.onExternalCollision() ^Javadoc to force collision resolution.

To summarize, Collision SPI provides developer with ability to use custom logic in determining how grid jobs should be scheduled and executed on a destination grid node.

Note that Collision SPI only controls job execution - it does not control task execution. So if you have a case where a node only emits tasks, but does not execute jobs, then Collision SPI will never be invoked on that node.

Job Rejection

If job is canceled while waiting for execution (job is on waiting list and execution has not started yet), then it will be rejected and GridJobResult ^Javadoc which is passed into GridTask.result(GridJobResult, List<GridJobResult>) ^Javadoc method will contain GridExecutionRejectedException ^Javadoc . You can access this exception by calling GridJobResult.getException() method.

Automatic Failover Note, that if you use any of GridTask Adapters, rejected jobs will be automatically failed over to another node. By default, jobs get automatically failed over only in case of job rejection or a node failure).

Job Cancellation

If job is canceled after it already was scheduled to execute, then GridJob.cancel() ^Javadoc method will be called on it (this method will also call Thread.interrupt() on the executing thread automatically). In this case cancellation is used as a notification to a job that it should stop executing. Just like with Java thread interruption, it is ultimately up to a job to finish executing and return result to caller. Your GridTask.result(GridJobResult, List<GridJobResult>) ^Javadoc implementation should decide if job result is acceptable and whether the job should be failed over to another node or not.

GridCollisionExternalListener

This listener is set on Collision SPI for notification of external collision events (e.g. job stealing). Once grid receives such notification, it will immediately invoke collision resolution.

GridGain uses this listener to enable job stealing from overloaded to underloaded nodes in GridJobStealingCollisionSpi. However, you can also utilize it, for instance, to provide time based collision resolution. To achieve this, you most likely would mark some job by setting a certain attribute in job context (see GridJobContext) for a job that requires time-based scheduling and set some timer in your Collision SPI implementation that would wake up after a certain period of time. Once this period is reached, you would notify this listener that a collision resolution should take place. Then inside of your collision resolution logic, you would find the marked waiting job and activate it.

Note that most collision SPI's may not have external or time-based collisions. In that case, they should simply ignore this method and do nothing when listener is set.

Configuration

GridCollisionSpi is provided in Grid Configuration passed into GridFactory ^Javadoc at startup. You can configure a different collision SPI implementation as follows

GridConfigurationAdapter cfg = new GridConfigurationAdapter();

GridFifoQueueCollisionSpi colSpi = new GridFifoQueueCollisionSpi();

// Limit number of parallel jobs.
colSpi.setParallelJobsNumber(10);

// Configure your own collisioin SPI.
cfg.setCollisionSpi(colSpi);

GridFactory.start(cfg);

Note that GridConfiguration ^Javadoc interface is just a bean and can also be configured using spring XML configuration.

For more information about using Spring framework for configuration click here.

Default Implementation

If no collision SPI is provided in configuration by default GridFifoQueueCollisionSpi is used.