Page History

...

Problem

Geode is comprised of multiple sub-projects , some of which make up the core system, and others of which add functionality to that core. All of that together enable all of Geode's features and functionality. Geode's sub-projects are included with Geode and are loaded when starting the system. However, only a small subset of the sub-projects are required for Geode to perform its basic functions–the rest are unnecessary unless/until the feature they add is used. For example, can be thought of as two categories: required and optional. Required sub-projects, like geode-core and geode-common are integral to the core system, but , 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, and geode-memcached are not. All of these non-essential sub-projects being bundled as part of Geode increases complexity in the code base and loading all of them at startup, even though they may going unused, means a larger memory footprint than is necessary. Also, since all sub-projects are loaded at startup, there is no way to add or modify features for an existing Geode instance. 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 problem problems and is unconcerned with...

...

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 loaded at startup time–the 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 load start Geode with only a subset of Geode's its sub-projects rather than all of them. It also becomes possible to load/unload modules at any time after Geode has startedand 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 core sub-projects/modules it requires to function and allow other modules to be loaded /unloaded at runtime, as they are needed. This can be done using the ManagementService proposed by the ClassLoader Isolation RFC. This solution also allows a deployed jar to be loaded as a module to add functionality to Geode on the fly–this means that new features could be developed more like plugins, in a separate codebase from the rest of Geode. This will allow Geode to start with only its basic functionality to conserve resources and to add/enable features at runtime by loading new modules, both from the predefined sub-projects and from newly deployed jar fileswill reduce Geode's memory footprint by keeping unused sub-projects out of memory until they're needed. 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.

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 normally.

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. 

...