To be Reviewed By: September 18th, 2020

Authors: Patrick Johnson

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: ClassLoader Isolation

Problem

Geode is comprised of sub-projects that together enable all of Geode's features and functionality. Geode's sub-projects can be thought of as two categories: required and optional. Required sub-projects, like geode-core and geode-common, have to be present for Geode to connect to clients, do put/get operations, and perform other basic functions. The optional sub-projects, like geode-lucene and geode-redis, add additional functionality to Geode but don't need to be present for Geode to perform it's core functions. Currently, all of the sub-projects are loaded onto the classpath at startup and all features are enabled even though they may go unused. Loading potentially unnecessary sub-projects increases Geode's memory footprint.


All sub-projects being loaded at startup is not only bad from a resource utilization perspective, but also from an extensibility perspective; features cannot be added or modified once Geode has started. This means that all features of Geode have to be shipped with it, increasing the complexity even if many of those features may seldom, or never, be used.

Anti-Goals

This proposal intends only to solve the above-stated problems and is unconcerned with...

  • Adding or removing any sub-projects from Geode.

Solution

After Geode is modularized, as proposed by the ClassLoader Isolation RFC, only a few sub-projects that are used to start the module system will be present on the classpath at startup–the rest will be loaded as modules at runtime. Since each module is loaded separately, it is possible to start Geode with only a subset of its sub-projects and because all module loading happens at runtime, modules can be loaded/unloaded after Geode starts.


The proposed solution is to start Geode with only the sub-projects/modules it requires to function and allow other modules to be loaded at runtime, as they are needed. This will reduce Geode's memory footprint by keeping unused sub-projects out of memory. When a feature that exists in an optional Geode sub-project is used (component created as per the Geode Components RFC) the containing sub-project will be loaded automatically, enabling new functionality on the fly. While exactly what sub-projects are required at startup is yet to be determined, at least the following modules will be required:

  • geode-core
  • geode-membership
  • geode-http-service
  • geode-tcp-server
  • geode-logging
  • geode-serialization
  • geode-common
  • geode-unsafe
  • geode-management

and at least the following modules will be optional:

  • geode-redis
  • geode-memcached
  • geode-lucene

The remaining sub-projects will be evaluated to determine if the functionality they provide is core to Geode.


The way modularization will be implemented, any jar file can be loaded as a module, meaning jars deployed via GFSHs deploy command can be loaded as modules. This would allow us to add totally new features to Geode at any time. Optional sub-projects, like geode-redis and geode-memcached, could even be moved out of the Geode codebase and packaged separately as extensions, reducing the size and complexity of core Geode.

Use Cases

Scenario 1: Geode starts up.

Expected behavior: geode-core and the other essential sub-projects are loaded and Geode performs its basic functions.

Scenario 2: Geode is told to create a component or start a service from one of the optional sub-projects (geode-redis, geode-lucene)

Expected behavior: The required sub-project is loaded and its functionality is enabled.

Scenario 3: A jar file is deployed using GFSHs deploy command. 

Expected behavior: The jar is loaded as a module and whatever functionality it provides is enabled. 

Changes and Additions to Public Interfaces

No changes or additions to public interfaces.

Performance Impact

Lower memory footprint in some cases.

Backwards Compatibility and Upgrade Path

No backward compatibility impact.

Prior Art

An alternative to this proposal is to simply load all sub-projects upfront as we currently do.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?


  • No labels