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.
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.
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 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.
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
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.
The following configuration parameters for peer class loading can be optionally configured in
Enables/disables peer class loading.
Configures thread pool to use for peer class loading. If not configured, a default one is used.
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.
List of packages in a system class path that should be P2P loaded even if they exist locally.
Size of missed resources cache. Set 0 to avoid missed resources caching.
Sets deployment mode for deploying tasks and classes.
<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