IDIEP-144
Author

 Unknown User (nizhikov) 

Sponsor
Created 20.02.2026
Status


Motivation

Ignite provide many ways to execute user provided code:

Currently, Ignite provides several ways to load user-provided code:

However, all this ways lack several crucial features:

We must reinvent the way Ignite loads user classes to fill the gap. 

Description

It proposed to add new entity to Ignite - IgniteClassPath.

IgniteClassPath properties:

API changes (list will be widen):

Required tools:

Examples:

$ ./control.sh --ignite-classpath create --name superapp_v1 --files ./my-app-v1.jar,./grpc-context-1.19.0.jar,./error_prone_annotations-2.1.3.jar
$ ./control.sh --ignite-classpath remove --name superapp_v0
$ ./control.sh --system-view IGNITE_CLASSPATHES
Ignite ignite = ...

IgniteCompute compute = ignite.compute(ignite.cluster().forServers());

// Running compute with the provided jars.
compute.withClasspath("superapp_v1").() -> {
    MyLibClass libClass = MyLibClass.getInstance();
    // other code.
};


ServiceConfiguration serviceCfg = new ServiceConfiguration();

serviceCfg.setName("mysuperappService_v1");
serviceCfg.setService(new MySuperappServiceImpl());
serviceCfg.setIgniteClasspath("mysuperapp_v1");

ignite.services().deploy(serviceCfg);

Other systems approaches:

Apache Spark

Provides a special tool - spark-submit  to deploy and execute jobs inside cluster.
It supports --jars argument to list jar files required by job. (1)

Apache Tomcat (2)

J2EE spec itself provide a clear way to:

Apache Flink (3) (4)

Provides an options to specify job classpath during starttime.

Example: 

$ ./bin/flink run -C /path/to/dependency.jar -c com.example.MyJob my-flink-job.jar

Design

There are two perspectives for ICP operations: a user perspective and a cluster perspective.

From a user perspective 4 main operations are allowed for ICP:

From a cluster perspective a deployment unit could be deployed on the cluster, but it could be not deployed on a particular node. So additional operation is required: create ICP on the target node (on demand).

Directories

All ICP must be placed in the ICP base directory which is a subdirectory under Ignite work directory:

<ignite_work_dir>/icp

For each ICP a directory should be created under the base directory. The name of this directory must be the same as ICP name and a nested directory for a particular version must be created. 

Example:

- icp
    - foo.example.job 
        - 1.0.0
        - 1.0.1
    - foo.example.task
        - 1.0.0
        - 2.0.0

Risks and Assumptions

We assume that p2p and deployment SPI will be removed from Ignite.

Users may want to recompile and refresh classes without changing (remove, create) existing IgniteClassPath during development or hotfix.
Currently, we don't have plans to support this kind of scenario.

We assume the following user scenarios:

Deploy and run first version of application:

  1. Pack jar files by regular procedures.
  2. Create IgniteClassPath in running cluster.
  3. Set name of classpath in app config.
  4. Start Ignite client nodes or connect via thin clients.
  5. Use classpath when starting jobs, services, etc.

Run second version of application in the same cluster:

  1. Pack jar files by regular procedures.
  2. Create second IgniteClassPath in running cluster.
  3. Restart some instances of user application with the updated version in config.
  4. Use updated classpath for new instances of application.
  5. When tested update all application instances.

With this approach, we can update applications without any outages.

Discussion Links

// Links to discussions on the devlist, if applicable.

Reference Links

  1. https://spark.apache.org/docs/latest/submitting-applications.html
  2. https://tomcat.apache.org/tomcat-11.0-doc/deployer-howto.html
  3. https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/debugging/debugging_classloading/
  4. https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/ops/rest_api/
  5. IEP-103: Code Deployment

Tickets

// Links or report with relevant JIRA tickets.