Apache Ignite Documentation

GridGain Developer Hub - Apache Ignitetm

Welcome to the Apache Ignite developer hub run by GridGain. Here you'll find comprehensive guides and documentation to help you start working with Apache Ignite as quickly as possible, as well as support if you get stuck.

 

GridGain also provides Community Edition which is a distribution of Apache Ignite made available by GridGain. It is the fastest and easiest way to get started with Apache Ignite. The Community Edition is generally more stable than the Apache Ignite release available from the Apache Ignite website and may contain extra bug fixes and features that have not made it yet into the release on the Apache website.

 

Let's jump right in!

 

Documentation     Ask a Question     Download

 

Javadoc     Scaladoc     Examples

Deployment Modes

Overview

Specifics of peer-class-loading behavior are controlled by different deployment modes. Particularly, the un-deployment behavior in cases when the originating, or master, node leaves a grid depends on the deployment mode. Other aspects, governed by deployment mode, are user resources management and class versions management. In the sections below we describe each deployment mode in more detail.

PRIVATE and ISOLATED

Classes deployed within the same class loader on the master node will still share the same class loader remotely on worker nodes. However, tasks deployed from different master nodes will not share the same class loader on worker nodes. This is useful in development when different developers can be working on different versions of the same classes.
There is no difference between PRIVATE and ISOLATED deployment modes since the @UserResource annotation has been removed. Both constants were kept for backward-compatibility reasons and one of them is likely to be removed in a future major release.

In this mode, classes get un-deployed when the master node leaves the cluster.

SHARED

This is the default deployment mode. In this mode, classes from different master nodes with the same user version will share the same class loader on worker nodes. Classes will be un-deployed whenever all master nodes leave the grid or user version changes. This mode allows classes coming from different master nodes to share the same instances of user resources on remote nodes (see below). This method is specifically useful in production as, in comparison to ISOLATED mode which has a scope of a single class loader on a single master node, SHARED mode broadens the deployment scope to all master nodes.

In this mode, classes get un-deployed when all the master nodes leave the cluster

CONTINUOUS

In CONTINUOUS mode, the classes do not get un-deployed when master nodes leave the grid. Un-deployment only happens when a class user version changes. The advantage of this approach is that it allows tasks coming from different master nodes that share the same instances of user resources (see Resource Injection) on worker nodes. This allows for all tasks executing on worker nodes to reuse, for example, the same instances of connection pools or caches. When using this mode, you can start up multiple stand-alone worker nodes, define user resources on master nodes, and have them initialized once on worker nodes regardless of which master node they came from. In comparison to the ISOLATED deployment mode which has a scope of a single class loader on a single master node, CONTINUOUS mode broadens the deployment scope to all master nodes which is specifically useful in production.

In this mode, classes do not get un-deployed even if all the master nodes leave the cluster.

Un-Deployment and User Versions

The class definitions, obtained with peer class loading, have their own lifecycle. On certain events (when master node leaves or user version changes, depending on deployment mode), the class information is un-deployed from the cluster: the class definition is erased from all nodes in the grid and the user resources, linked with that class definition, are also optionally erased (again, depending on deployment mode).

User version comes into play whenever you want to redeploy classes deployed in SHARED or CONTINUOUS modes. By default, Ignite will automatically detect if the class loader has changed or a node is restarted. However, if you would like to change and redeploy the code on a subset of nodes, or in the case of CONTINUOUS mode, kill every living deployment, you should change the user version.
User version is specified in the META-INF/ignite.xml file of your class path as follows:

<!-- User version. -->
<bean id="userVersion" class="java.lang.String">
    <constructor-arg value="0"/>
</bean>

By default, all Ignite startup scripts (ignite.sh or ignite.bat) pick up the user version from the IGNITE_HOME/config/userversion folder. Usually, you just need to update the user version under that folder. However, in case of GAR or JAR deployment, you should remember to provide the META-INF/ignite.xml file with the desired user version in it.

Configuration

The following configuration parameters for peer class loading can be optionally configured in IgniteConfiguration:

Setter Method

Description

Default

setPeerClassLoadingEnabled(boolean)

Enables/disables peer class loading.

false

setPeerClassLoadingExecutorService(ExecutorService)

Configures thread pool to use for peer class loading. If not configured, a default one is used.

null

setPeerClassLoadingExecutorServiceShutdown(boolean)

Peer class loading executor service shutdown flag. If the flag is set to true, the peer class loading thread pool will be forcibly shut down when the node stops.

true

setPeerClassLoadingLocalClassPathExclude(String...)

List of packages in a system class path that should be P2P loaded even if they exist locally.

null

setPeerClassLoadingMissedResourcesCacheSize(int)

Size of missed resources cache. Set 0 to avoid missed resources caching.

100

setDeploymentMode(DeploymentMode)

Sets deployment mode for deploying tasks and classes.

SHARED

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!--
        Explicitly enable peer class loading. Set to false
        to disable the feature.
    -->
    <property name="peerClassLoadingEnabled" value="true"/>
     
    <!-- Set deployment mode. -->
    <property name="deploymentMode" value="CONTINUOUS"/>
 
    <!-- Disable missed resources caching. -->
    <property name="peerClassLoadingMissedResourcesCacheSize" value="0"/>
 
    <!--
        Exclude force peer class loading of a class,
        even if exists locally.
    -->
    <property name="peerClassLoadingLocalClassPathExclude">
        <list>
            <value>com.mycompany.MyChangingClass</value>
        </list>
    </property>
</bean>
IgniteConfiguration cfg=new IgniteConfiguration();

// Explicitly enable peer class loading.
cfg.setPeerClassLoadingEnabled(true);

// Set deployment mode.
cfg.setDeploymentMode(DeploymentMode.CONTINUOUS);

// Disable missed resource caching.
cfg.setPeerClassLoadingMissedResourcesCacheSize(0);

// Exclude force peer class loading of a class, 
// even if it exists locally.
cfg.setPeerClassLoadingLocalClassPathExclude("com.mcompany.MyChangingClass");

// Start a node.
Ignition.start(cfg);

Updated about a year ago

Deployment Modes


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.