You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 multiple sub-projects, some of which make up the core system, and others of which add functionality to that core. All of 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, geode-core and geode-common are integral to the core system, but geode-lucene, 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. 

Anti-Goals

This proposal intends only to solve the above-stated problem 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 will be loaded at startup time–the rest will be loaded as modules at runtime. Since each module is loaded separately, it is possible to load only a subset of Geode's sub-projects rather than all of them. It also becomes possible to load/unload modules at any time after Geode has started.


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

Use Cases

Scenario 1: Geode starts up.

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

Scenario 2: Geode is told to create a component or start a service from one of the non-essential 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