General Ideas

  • Rename GridFutureAdapter and other Ignite Core classes that misuse "adapter" term.
  • Remove AbstractFailureHandler.ignoredFailureTypes: critical failures should be handled, not masked. (There is no ideas about how exactly handle unknown errors. Discussion: http://apache-ignite-developers.2346864.n4.nabble.com/GridDhtInvalidPartitionException-takes-the-cluster-down-td41459.html )
  • Make 'pairedConnections' on by default in TcpCommunicationSpi?
  • Implement new BinaryObject with field type changes and constant-time access to constant-length fields.
  • Rename configuration checkpointFrequency to checkpointInterval (or probably other options used Frequency word but really meaning Interval)
  • For all versioned FooBarerV3 classes, etc, remove all previous V2,  versionless classes, make it the only one without V3.
  • Replace home-brewed GridFutureAdapter with standard CompletableFuture?
  • Restructure future interfaces: IgniteInternalFuture should extend IgniteFuture.
  • Support Java9+ Automatic modules ( https://issues.apache.org/jira/browse/IGNITE-11461 ) for all Jars.
  • Reorder modules tree:
    • group ignite-spring, ignite-flume- ignite-spar, iginte-camel, ignite-cassandra into ignite/integrations
    • group ignite-dev-utils, ignite-benchmarks, ignite-tools  into ignite/dev-support
    • etc...
  • Get rid of words Ignite, Grid in internal classes. Examples: GridFutureAdapter, GridManager, GridProcessor, etc...
  • Get rid of "use..." or "...Enabled" in boolean properties' names.
  • .NET: Target .NET Standard 2.0, discontinue .NET 4.0 support
  • Redesign REST protocol. 
  • Make most of options are runtime configurable.
  • Change `Object consistentId` to `String consistentId` because String is much more safer. User by mistake can set consistentId with not serializable object.
  • Make IgniteConfiguration immutable, so that you can start two nodes from some IgniteConfiguration (node startup should not change cfg in any ways).
  • Client nodes should pick up configuration from cluster (such as binary configuration, peer class loading, etc) instead of reporting mismatch.
  • Support heterogenous clusters with nodes of different versions.
  • Remove all compatibility checks and hooks for any specific 2.x versions since there is no compatibility in 2.x or with 2.x.
  • Logging overhaul: If logging implementation in classpath, it should be choosen automatically with sensible default config if user config not present. There should be no IGNITE_CONSOLE_APPENDER
  • provide "out of the box" SQL API without any strange query through cache instance. Something like ignite.sql().query("SELECT * FROM table")
  • Resurrect fair affinity.
  • Raise maximum number of partitions to allow more nodes in a single grid. Currently we have a theoretical maximum of ~2k (if 32 primary partitions per node). Or even better rework current approach to partitioning to allow unlimited number of nodes.
  • Remove BinaryUtils#FIELDS_SORTED_ORDER and use sorted order by default.
  • Make java thin client API consistent with thick API (discussion: http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Consistency-across-java-thin-thick-APIs-td48914.html).

To Be Removed List For Discussion

  • Local caches (they are useless but require a lot of time to be supported)
  • Scalar - it is already extremely outdated and noone asks for an update
  • Visorcmd - a node that is always connected to the grid may be a destabilizing behavior; actionable utilities like control.sh make more sense
  • Full text and spacial indexes - they are not persistent; should be rewritten for durable memory later on
  • Schedule module - hardly used, local-only scheduling (same issues as with local cache)
  • Explicit locks outside the transaction - lock concept is broken in a distributed system
  • Modules with legacy library versions: hibernate-4.2, hibernate-5.1, spring-data, visor-console-2.10, etc?
  • Remove current data structures (Lock, Semaphore, Set, Queue). Cache-based implementation leads to configuration issues. May be implemented on top of cache API in an auxiliary library or have an internal cache-free implementation
  • AOP - hard to believe it's used
  • Deprecated metrics - kept only for backward compatibility
  • Checkpoint SPI - regular caches may be used as a storage, no need for another storage abstraction
  • Old thin client and old JDBC connector
  • GAR files - should be replaced with JAR files, no need for tasks scan inside the jar. Also, remove IgniteCompute methods executing tasks by task name
  • Deprecated methods, fields and classes marked with `@deprecated`. Also revive IGNITE-6301 to remove indexedTypes field
  • As many IGNITE_ parameters as possible from IgniteSystemProperties
  • "Force server mode" for client nodes
  • JSR107 (JCache) compatibility (useless but require a time to be supported) 

  • ForceKeyRequests and related code. Since we have Late affinity assignment and primary node partitions are always up to date we don't need to request actual data from backups

  • @CentralizedAffinityFunction and related code. I don't see any real usages of custom affinity functions that use this annotation

  • Leave Exchanges Merge + Late Affinity assignment as the only PME protocol. Remove centralized affinity distribution in case of node left and no merge exchange legacy modes

  • CacheRebalanceMode.NONE and Rebalance Delay as it can break data consistency in a cluster. Also, remove force rebalance mode as it can be used only if rebalance delay is set

  • .NET: Legacy Entity Framework and ASP.NET integrations
  • Daemon nodes
  • Near cache - extremely rare deliberate usage, performance issues, slowdowns new features development, a lot of "if near() then skip test" at TeamCity
  • DiscoverySpi#failNode and other "for tests only" public methods.
  • Redis and Memcached protocols support
  • IndexingSpi (question)
  • Old Service Grid implementation
  • QueryEntity and annotation based indexed types configuration
  • CacheFileLocalStore - obsolete, have native persistence now
  • Get rid of ignite-shmem
  • Get rid of Discovery & Communication compatibility with previous versions (Ignite does not allow heterogeneous clusters).
  • Get rid of cache groups, instead provide another way to support large number of caches.
  • Get rid of custom affinity support (and other user closures in a configuration as many as possible)


  • No labels

Apache Ignite