The closures and tasks that you use for your computations may be of any custom class, including anonymous classes. In Ignite, the remote nodes will automatically become aware of those classes, and you won't need to explicitly deploy or move any .jar files to any remote nodes.
Zero Deployment behavior is possible due to peer class loading (P2P class loading), a special distributed ClassLoader in Ignite for inter-node byte-code exchange. With peer-class-loading enabled, you don't have to manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes.
A code example like below would run on all remote nodes due to peer class loading, without any explicit deployment step.
IgniteCluster cluster = ignite.cluster(); // Compute instance over remote nodes. IgniteCompute compute = ignite.compute(cluster.forRemotes()); // Print hello message on all remote nodes. compute.broadcast(() -> System.out.println("Hello node: " + cluster.localNode().id()));
Here is how peer class loading can be configured:
<bean class="org.apache.ignite.configuration.IgniteConfiguration"> ... <!-- Explicitly enable peer class loading. --> <property name="peerClassLoadingEnabled" value="true"/> ... </bean>
IgniteConfiguration cfg = new IgniteConfiguration(); cfg.setPeerClassLoadingEnabled(true); // Start Ignite node. Ignite ignite = Ignition.start(cfg);
Peer class loading sequence works as follows:
- Ignite will check if class is available on local classpath (i.e. if it was loaded at system startup), and if it was, it will be returned. No class loading from a peer node will take place in this case.
- If class is not locally available, then a request will be sent to the originating node to provide class definition. Originating node will send class byte-code definition and the class will be loaded on the worker node. This happens only once per class - once class definition is loaded on a node, it will never have to be loaded again.
Auto-Clearing Caches for Hot Redeployment
Use BinaryMarshaller (default) with hot redeployment. If you don't use BinaryMarshaller, that is set by default, then whenever you change class definitions for the data stored in cache, Ignite will automatically clear the caches for previous class definitions before peer-deploying the new data to avoid class-loading conflicts.
3rd Party Libraries
When utilizing peer class loading, you should be aware of the libraries that get loaded from peer nodes vs. libraries that are already available locally in the class path. Our suggestion is to include all 3rd party libraries into class path of every node. This can be achieved by copying your JAR files into the Ignite
libsfolder. This way you will not transfer megabytes of 3rd party classes to remote nodes every time you change a line of code.
To deploy your JAR files into Ignite explicitly, you should copy them into the
libs folder on every Ignite cluster member. Ignite will automatically load all the JAR files from the
libs folder on startup.
Updated less than a minute ago