You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 43
Next »
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 the single grid. Currently we have a theoretical maximum of ~2k (if 32 primary partitions per node).
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)](/confluence/s/34gb19/8804/10mvnxf/_/images/icons/emoticons/help_16.svg)
- 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)