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

Zero Deployment


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.

Peer Class Loading

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"/>
IgniteConfiguration cfg = new IgniteConfiguration();


// Start Ignite node.
Ignite ignite = Ignition.start(cfg);

Peer class loading sequence works as follows:

  1. 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.
  2. 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 libs folder. This way you will not transfer megabytes of 3rd party classes to remote nodes every time you change a line of code.

Explicit Deployment

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

Zero Deployment

Suggested Edits are limited on API Reference Pages

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