Spring Data Geode Region has local scope and cannot listen to remote Region events

Question

I am using Spring Data for Apache Geode for a Spring Boot app that uses a remote Apache Geode server. To set up local Regions I am using @Configuration class like:

@Configuration
public class GeodeConfig {

  public static Region<String, String> myRegion;

  @Bean("setupMyRegion")
  public Region<String, String> setupMyRegion(GemFireCache cache) {

    Region<String, String> r = cache.getRegion("myRegion");
    myRegion = r;

    return r;
  }
}

This enables me to put and get data with the Region.

When I register interest in subscribing to a key, the subscription is setup with scope=LOCAL like this:

org.apach.geode.inter.cache.LocalRegion 4439 logKeys: org.apache.geode.internal.cache.LocalRegion[path='/myRegion';scope=LOCAL';dataPolicy=NORMAL; concurrencyChecksEnabled] refreshEntriesFromServerKeys count=1 policy=KEYS_VALUES

and I guess that I want to set it up as a CACHING_PROXY so that later, on subscribing to events in the Region, the local subscription will see the server Region events.

I've set subscriptionEnabled=TRUE for the @ClientCacheApplication and I am trying to set

clientRegionShortcut = ClientRegionShortcut.CACHING_PROXY 

I don't know where to do this. I've tried the @EnableClusterDefinedRegions annotation but the Region is still being set to local.

If I try to create a Region Factory from the GemFireCache it gives me an error that the method createClientRegionFactory(ClientRegionShortcut) is "undefined" for the type GemFireCache.

THANKS

Answer 1

Generally, it is bad practice to use the Apache Geode API directly to configure beans in a Spring context. For example...

  @Bean("MyRegion")
  public Region<String, Object> myRegion(GemFireCache cache) {
    return cache.getRegion("myRegion");
  }

Or using:

  @Bean("MyRegion")
  public Region<String, Object> myRegion(ClientCache clientCache) {
    return clientCache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
      .create("MyRegion");
  }

Both approaches above are not recommended!

Spring Data for Apache Geode (SDG) contains specific Spring FactoryBeans to do the same thing. For instance, the SDG ClientRegionFactoryBean.

You would use the ClientRegionFactoryBean in your Spring application configuration as follows:

@Bean("MyRegion")
ClientRegionFactoryBean<String, Object> myRegion(ClientCache clientCache) {

  ClientRegionFactoryBean<String, Object> myRegion = 
    new ClientRegionFactoryBean<>();

  myRegion.setCache(clientCache);
  myRegion.setShortcut(ClientRegionShortcut.CACHING_PROXY);

  return myRegion;
}

There are SDG FactoryBeans for different types of Geode objects, such a [client] Regions, Indexes, DiskStores, GatewayReceivers, GatewaySenders, etc.

These FactoryBeans are essential in ensuring the the "lifecycle" of the Geode objects (e.g. Region(s)) are properly synced to the lifecycle of the Spring container. By forgoing the use of SDG's FactoryBeans you are effectively ignoring the lifecycle coordination provided by the Spring container and custom (framework) FactoryBeans, and are therefore responsible for the lifecycle of the Geode objects themselves when using Geode's API direct in Spring config. This is one of the primary reasons SDG's exists in the first place.

A "client" Region must be a *PROXY (e.g. PROXY or CACHING_PROXY) in order to enable subscriptions and receive interesting events from servers for that Region. This is because the Geode cluster (servers) maintain a subscription queue for clients when they connect, which contain events that the client has expressed interests in receiving.

For *PROXY client Regions, this also means that the client Region must have a corresponding server-side, peer cache Region by the same name.

You can simplify Region creation in general, and client Region creation in particular, by using SDG's Annotation-based configuration model, and specifically, @EnableEntityDefinedRegions or @EnableCachingDefinedRegions.

For instance:

@ClientCacheApplication(subscriptionsEnabled = true)
@EnableEntityDefinedRegions(basePackageClasses = SomeEntity.class, 
  clientRegionShortcut = ClientRegionShortcut.CACHING_PROXY)
class GeodeConfiguration {
  ...
}

Of course, this assumes you have defined application domain model entity classes, such as:

package example.app.model;

import ...;

@Region("MyRegion")
class SomeEntity {

  @Id
  private Long id;

  ...
}

The ClientRegionFactoryBean would be typed accordingly: ClientRegionFactoryBean<Long, SomeEntity>.

See the SDG Annotation-based configuration model documentation for more details, and specifically Annotation configuration covering Region definitions.

The @EnableClusterDefinedRegions annotation defines client-side Regions for all existing server-side (cluster) Regions to which the client connects.

For example, if you start a cluster in Gfsh as follows:

gfsh>start locator --name=MyLocator ...

gfsh>start server --name=MyServer ...

gfsh>create region --name=Example --type=PARTITION

gfsh>create region --name=AnotherExample --type=REPLICATE

And then connect a Spring Boot, Apache Geode ClientCache application to this cluster by using the following Geode configuration:

@ClientCacheApplication
@EnableClusterDefinedRegions(clientRegionShortcut = 
  ClientRegionShortcut.CACHING_PROXY)
class GeodeConfiguration {
  ...
}

Then the Spring Boot, Apache Geode ClientCache application would have 2 Spring configured client Region beans with names "Example" and "AnotherExample" both of type, CACHING_PROXY.

If there are NO server-side Regions presently in the cluster, then the @EnableClusterDefinedRegions would not define any client-side Regions.

Anyway, I hope this makes sense and helps!

Cheers!

Answer 2

The main problem here was that the class in which I wanted to use the Geode regions was not registering in the Spring container because I was using new to use that class instead of using @Autowired annotation for Spring. That meant that when I setup the Geode regions per @JohnBlum's answer using @Resource(name = "Example") private Region<Object, Object> example the autowiring was still producing null objects.

Also the class where I wanted to use the regions was in another package outside of my @ComponentScan so I had to amend the @ComponentScan to find that package.

Thing is, once I got through these configurations and properly setup the @EnableClusterDefinedRegions (real easy once you know how!!) and I can put and get with the regions, the register interests doesn't work.

The problem with the register interests was that my application.properties had

spring.data.gemfire.cache.client.durable-client-id=myListener

and when I removed that property the CacheListenerAdapter started to receive events from the server!