Unable to create Global region using Spring Data Geode/Gemfire

Question

From spring data geode/gemfire, can we create Regions on the cluster ? Currently it is creating local cache region but any configuration being done either in ClientCache mode or ServerCache mode, doesn't have any impact on the Cluster server.

But using gfsh commands if we create a REPLICATE Region then the connectivity works fine. Is that the only way to create a REPLICATE region in Gemfire/Geode cluster ?

Next, there are many documentation which refers to Region with GLOBAL scope but again in gfsh there is no way to create a Region with Scope GLOBAL, nor I could locate any configuration via Spring data geode.

Do we have any additional information on this ?

Regards, Malaya

Searched the Geode/Gemfire documentation regarding any commannds but couldn't find any.

Tried to adapt the spring data geode/gemfire but even there also there is no option of GLOBAL region creation.

Answer 1

Spring Data for Apache Geode (SDG) does support pushing configuration metadata for Apache Geode Regions (and other Apache Geode objects, e.g. Indexes) to the cluster of servers using the SDG Cluster Configuration Push feature. However, this feature currently only pushes the Region "name" and DataPolicy type (Javadoc) to the servers from the client.

Additionally, "Cluster Configuration Push" only applies when your Spring [Boot] Data application is an Apache Geode ClientCache. If the application is a peer Cache, then this feature does not apply.

NOTE: Spring Boot for Apache Geode (SBDG) applies additional features on top of SDG's Cluster Configuration Push feature. See here. Again, this applies to clients only.

AFAIR, Scope.GLOBAL Regions only applies to REPLICATE Regions, first of all. That is, you cannot create a "GLOBAL" PARTITION Region. See Apache Geode docs for further details on Scope along with other Region distribution configuration attributes.

Assuming your Spring [Boot] Data for Apache Geode application were a peer Cache instance, then you can configure your REPLICATE Regions with a "GLOBAL" Scope as follows:

// Alternatively, you can use @CacheServerApplication
@PeerCacheApplication(name = "MySpringGeodeServer")
class MySpringDataGeodeApplication {

  @Bean("MyRegion")
  ReplicatedRegionFactoryBean myReplicateRegion(GemFireCache cache) {

    ReplicatedRegionFactoryBean region = new ReplicatedRegionFactoryBean();

    region.setCache(cache);
    region.setScope(Scope.GLOBAL);

    return region;
  }
}

However, keep in mind this peer Cache, Spring-configured server application is NOT going to push the configuration to other servers in the cluster.

If you are using SDG Annotation-based configuration to (dynamically & conveniently) create Regions in your Spring peer Cache application, for example: using either @EnableEntityDefinedRegions or perhaps @EnableCachingDefinedRegions, then you will need to additionally rely on 1 or more RegionConfigurer bean definitions (see docs) to customize the configuration of individual Regions as the Annotation-based support does not enable fine-grained Region configuration customization of this nature (e.g. Scope on REPLICATE Regions).

This might look something like the following.

Given a persistent entity:

@Region("Customers")
class Customer { 
  // ...
}

Then:

@CacheServerApplication(name = "MySpringGeodeServer")
@EnableEntityDefinedRegions(
  basePackageClasses = Customer.class,
  serverRegionShortcut = RegionShortcut.REPLICATE
)
class MySpringDataGeodeApplication {

  @Bean
  RegionConfigurer customerRegionConfigurer() {

    return new RegionConfigurer() {

      @Override
      public void configure(String beanName, PeerRegionFactoryBean<?, ?> region) {

        if ("Customers".equals(beanName)) {
          ((ReplicatedRegionFactoryBean) region).setScope(Scope.GLOBAL);
        }
      }

    }
  }
}

NOTE: Alternatively, if you need such fine-grained control over Region (bean) configuration like this, then you should simply use the Java-based configuration rather than Annotations, anyway. Annotation-based configuration is primarily provided for convenience; it is not a 1-size fits all by any means.

Technically, you could also annotate your persistent entity classes (e.g. Customer) with 1 of the Region type-specific mapping annotations (Javadoc), rather than simply the generic @Region mapping annotation, as well, such as with @ReplicateRegion. This allows you to do things like:

@ReplicateRegion(name = "Customers", scope = Scope.GLOBAL)
class Customer {
  // ...
}

Still, I generally prefer users to simply use the generic @Region mapping annotation, and again, if they need to do low-level configuration of Regions (like setting "Scope" on a REPLICATE Region) then simply use Java-based configuration as the opening example demonstrated.

Still, keep in mind, none of this is shared across the other servers inside the same cluster. Spring peer Cache applications do NOT push configuration metadata to other servers at all, and never will. This is sort of the point of using Apache Geode's Cluster Configuration Service anyhow.

NOTE: SDG peer Cache applications can be enabled (disabled by default) to inherit configuration from an existing cluster using Apache Geode's Cluster Configuration Service. For instance, see the useClusterConfiguration attribute (Javadoc) on the PeerCacheApplication annotation. There are strong reasons why SDG disabled this peer/server-side feature by default.

Upon reviewing this and this (not that Scope is something you can "alter" on a Region after the fact anyway), you are CORRECT, when using Gfsh, you cannot create a GLOBAL Scoped REPLICATE Region in the cluster, :(

In general, keep in mind that anything that is possible to do with Apache Geode's API, you can definitely do with Spring (Boot/Data) for Apache Geode and then some.

This is due in large part because SDG was built on Apache Geode's API and not some tool, like Gfsh.