Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Release Manager

Valentin Kulichenko

Development Process

All the development for the Apache Ignite 3.x happens in the dedicated repository: https://github.com/apache/ignite-3

TeamCity is currently set up to run all available JUnit tests (this will be changed in the future): https://ci.ignite.apache.org/project/ignite3

TeamCity triggers the test run for a pull request when it's created or updated. Upon completion, the PR is updated with the corresponding status which is shown as a successful or failed check.

The basic process to make a change is the following:

  1. A contributor develops in their own fork and creates a PR when done.
  2. TeamCity triggers a test run and updates the PR with the status. The same happens if PR is updated.
  3. A committer reviews the code and merges the PR directly from GitHub. The merge is allowed only if the test check is passed.

Meetups

On the week of Sep 14th, we had two virtual events where the community discussed the proposed changes.

In English:

Widget Connector
urlhttps://www.youtube.com/watch?v=zPuLJgUfLaM

In Russian:

Widget Connector
urlhttps://www.youtube.com/watch?v=vXFAwTsYI5g

Slides are available here.

Major Changes and Features

...

Some of the modules (mainly, integration components and thin clients) can be isolated into separate projects with independent lifecycles.

GraalVM Native Image Support

GraalVM is gaining a lot of popularity, especially in the context of serverless environments and frameworks like Micronaut and Quarkus. Currently, even Ignite thin client blocks software from being built into a native GraalVM image – this needs to be fixed. Preferably, we should support this for thick clients as well, although this is a lower priority and might require much bigger effort.

Cleanup

Ignite 3.0 is a major release, which gives us a unique opportunity to make incompatible changes. This can be used to do a cleanup and remove deprecated APIs and features. Additionally, all APIs should be revisited from this point of view – anything that is not relevant anymore should be removed from the project; some APIs can be reworked and modernized.

TBD: full list List of removals.

GraalVM Native Image Support

proposed removals (WIP):

  • *Resource annotations except for the IgniteInstanceResource 
  • Job scheduler API
  • Messaging API
  • Gridify/AOP
  • On-heap cache and eviction policies (question)
  • IGFS and Hadoop Accelerator
  • Indexing SPI
  • Communication and discovery SPIs (should be internal components not exposed to the public API)
  • Checkpoint SPI
  • Mesos and Yarn integrations
  • OSGi integration
  • Local caches
  • Scalar
  • Explicit locks (question)
  • GAR file deployment
  • "Force server" mode for client nodes
  • CacheRebalanceMode  and rebalance delay - should always work in the ASYNC  mode (current default)
  • Daemon nodes
  • Custom affinity functions
  • Visor (should be replaced with a unified tool)
  • Daemon mode
  • Force server mode for client nodes
  • Unnecessary rebalance modes (only ASYNC makes sense) and parameters

Other changes

  • Replace IgniteFuture  with Java's CompletableFuture 
  • The consistent ID should be a String, not a generic Serializable object

Issues

Label ignite-3  is used for any issues in JIRA that are related to Ignite 3.x.

Jira
serverASF JIRA
columnskey,summary,type,updated,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryfilter=12349470
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
GraalVM is gaining a lot of popularity, especially in the context of serverless environments and frameworks like Micronaut and Quarkus. Currently, even Ignite thin client blocks software from being built into a native GraalVM image – this needs to be fixed. Preferably, we should support this for thick clients as well, although this is a lower priority and might require much bigger effort.