Add support to protect against Apache Geode Initialization Safety Issues in a DI context

[jxblum]

Apache Geode and VMware Tanzu GemFire are rife with initialization safety issues, particularly when using the GemFire/Geode APIs to configure and bootstrap GemFire/Geode servers in an application context.

Many users use Spring Data for Apache Geode's (SDG) highly powerful and convenient programming model and Annotation support, or by far greater extension, Spring Boot for Apache Geode's (SBDG) auto-configuration, to configure and bootstrap GemFire/Geode Locators and Servers, especially for application development and testing, but even when deploying to Apache Geode (GemFire) applications to production.

Unfortunately, while Apache Geode (GemFire) is a powerful and reliable data management technology, it is not application developer friendly and it is all too easy for developers to run into issues when developing application components using Apache Geode's (GemFire's) APIs to extend the functionality and behavior of Apache Geode's (GemFire's) data management capabilities with application-specific logic.

Extending Apache Geode (GemFire) data management capabilities is often achieved by developing cache callbacks, such as CacheListener, CacheLoaders or CacheWriters (synchronous) callbacks. It is possible that these application components and extensions to a GemFire/Geode cache maybe called before the GemFire/Geode cache (system) is fully initialized, leading to unpredictable behavior, deadlocks and even data loss. This is even true when using AEQ's with application listeners in an asynchronous manner.

To make matters worse, Apache Geode (GemFire) does not even protect against itself (when using various APIs to configure and initiate GemFire/Geode objects/components). For example, WAN GatewayReceivers used to process data events originating from a remote cluster that are of interests to the target cluster, yet the target cluster may not be fully initialized and ready before the GatewayReceiver in the target cluster is up and running and receiving events from the remote cluster. This can happen for instance if the Region is performing a GII.

All of this leads to very confusing and incorrect behavior by the user's application of Apache Geode. This can happen whether you are using Spring, and in particular, Spring Boot/Spring Data for Apache Geode, or not. Meaning, the same effect can occur even when developing Java applications using Apache Geode's (GemFire's) own APIs directly. Indeed SDG, and by extension, SBDG, simply using Apache Geode's (GemFire's) APIs under the hood.

This Issue ticket is meant to address this problem and shortcoming in Apache Geode's (GemFire's) API with Spring.

[jxblum]

This Issue ticket originated from Spring Boot for Apache Geode (SBDG) Issue #78 and is moving to Spring Data for Apache Geode (SDG) for resolution.

[jxblum]

A prototype and POC of this solution has already been developed based on the requirements of a particular GemFire customer involving cache callbacks.

Another GemFire customer has run into a similar issue that now involves WAN Gateway components, and in particular a GatewayReceiver available and running in a target cluster that has not been fully initialized yet.