Page History

...

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

...