Package org.apache.ignite.configuration

Enum DeploymentMode

  • All Implemented Interfaces:
    Serializable, Comparable<DeploymentMode>
    public enum DeploymentMode
extends Enum<DeploymentMode>
    Grid deployment mode. Deployment mode is specified at grid startup via IgniteConfiguration.getDeploymentMode() configuration property (it can also be specified in Spring XML configuration file). The main difference between all deployment modes is how classes are loaded on remote nodes via peer-class-loading mechanism.

    The following deployment modes are supported:

    User Version

    User version comes into play whenever you would like to redeploy tasks deployed in SHARED or CONTINUOUS modes. By default, Ignite will automatically detect if class-loader changed or a node is restarted. However, if you would like to change and redeploy code on a subset of nodes, or in case of CONTINUOUS mode to kill the ever living deployment, you should change the user version.

    User version is specified in META-INF/ignite.xml file 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 user version from IGNITE_HOME/config/userversion folder. Usually, it is just enough to update user version under that folder, however, in case of GAR or JAR deployment, you should remember to provide META-INF/ignite.xml file with desired user version in it.

    Always-Local Development

    Ignite deployment (regardless of mode) allows you to develop everything as you would locally. You never need to specifically write any kind of code for remote nodes. For example, if you need to use a distributed cache from your ComputeJob, then you can the following:
    1. Simply startup stand-alone Ignite nodes by executing IGNITE_HOME/ignite.{sh|bat} scripts.
    2. Now, all jobs executing locally or remotely can have a single instance of cache on every node, and all jobs can access instances stored by any other job without any need for explicit deployment.

    • Enum Constant Detail

      • PRIVATE

        public static final DeploymentMode PRIVATE
        In this mode deployed classes do not share resources. Basically, resources are created once per deployed task class and then get reused for all executions.

        Note that classes deployed within the same class loader on 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, which is useful in development when different developers can be working on different versions of the same classes.

        Also note that resources are associated with task deployment, not task execution. If the same deployed task gets executed multiple times, then it will keep reusing the same user resources every time.

      • ISOLATED

        public static final DeploymentMode ISOLATED
        Unlike PRIVATE mode, where different deployed tasks will never use the same instance of resources, in ISOLATED mode, tasks or classes deployed within the same class loader will share the same instances of resources. This means that if multiple tasks classes are loaded by the same class loader on master node, then they will share instances of resources on worker nodes. In other words, user resources get initialized once per class loader and then get reused for all consecutive executions.

        Note that classes deployed within the same class loader on 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, which is especially useful when different developers can be working on different versions of the same classes.

      • SHARED

        public static final DeploymentMode SHARED
        Same as ISOLATED, but now tasks from different master nodes with the same user version and same class loader will share the same class loader on remote nodes. Classes will be undeployed whenever all master nodes leave grid or user version changes.

        The advantage of this approach is that it allows tasks coming from different master nodes share the same instances of resources on worker nodes. This allows for all tasks executing on remote nodes to reuse, for example, the same instances of connection pools or caches. When using this mode, you can startup multiple stand-alone Ignite worker nodes, define resources on master nodes and have them initialize once on worker nodes regardless of which master node they came from.

        This method is specifically useful in production as, in comparison to ISOLATED deployment mode, which has a scope of single class loader on a single master node, this mode broadens the deployment scope to all master nodes.

        Note that classes deployed in this mode will be undeployed if all master nodes left grid or if user version changed. User version can be specified in META-INF/ignite.xml file as a Spring bean property with name userVersion. This file has to be in the class path of the class used for task execution.

        SHARED deployment mode is default mode used by the grid.

      • CONTINUOUS

        public static final DeploymentMode CONTINUOUS
        Same as SHARED deployment mode, but resources will not be undeployed even after all master nodes left grid. Tasks from different master nodes with the same user version and same class loader will share the same class loader on remote worker nodes. Classes will be undeployed whenever user version changes.

        The advantage of this approach is that it allows tasks coming from different master nodes share the same instances of resources on worker nodes. This allows for all tasks executing on remote nodes to reuse, for example, the same instances of connection pools or caches. When using this mode, you can startup multiple stand-alone Ignite worker nodes, define resources on master nodes and have them initialize once on worker nodes regardless of which master node they came from.

        This method is specifically useful in production as, in comparison to ISOLATED deployment mode, which has a scope of single class loader on a single master node, CONTINUOUS mode broadens the deployment scope to all master nodes.

        Note that classes deployed in CONTINUOUS mode will be undeployed only if user version changes. User version can be specified in META-INF/ignite.xml file as a Spring bean property with name userVersion. This file has to be in the class path of the class used for task execution.

    • Method Detail

      • values

        public static DeploymentMode[] values()
        Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows: 
        for (DeploymentMode c : DeploymentMode.values())
    System.out.println(c);
        Returns:
        an array containing the constants of this enum type, in the order they are declared

      • valueOf

        public static DeploymentMode valueOf​(String name)
        Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
        Parameters:
        name - the name of the enum constant to be returned.
        Returns:
        the enum constant with the specified name
        Throws:
        IllegalArgumentException - if this enum type has no constant with the specified name
        NullPointerException - if the argument is null

      • fromOrdinal

        @Nullable
public static @Nullable DeploymentMode fromOrdinal​(int ord)
        Efficiently gets enumerated value from its ordinal.
        Parameters:
        ord - Ordinal value.
        Returns:
        Enumerated value.