Pivotal GemFire 9.1.1: Replicated Region not created in cluster - gemfire

Question

I have a GemFire cluster with 2 Locators and 2 Servers in two unix machines. I am running a Spring Boot app which joins the GemFire cluster as a peer and tries to create Replicated Regions, loading the Regions using Spring Data GemFire. Once the Spring Boot app terminates, I am not seeing the Region/data in cluster.
Am I missing something here?
GemFire cluster is not using cache.xml or Spring XML to bootstrap the Regions. My idea is to create Regions through a standalone program and make it available in the cluster. SDGF version is 2.0.7.
gemfire-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="http://www.springframework.org/schema/gemfire"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">
<util:properties id="gemfireProperties">
<prop key="locators">unix_machine1[10334],unix_machine2[10334]</prop>
<prop key="mcast-port">0</prop>
</util:properties>
<bean id="autoSerializer" class="org.apache.geode.pdx.ReflectionBasedAutoSerializer">
<gfe:cache properties-ref="gemfireProperties" pdx-serializer-ref="autoSerializer" pdx-read-serialized="true"/>
<gfe:replicated-region id="Test" ignore-if-exists="true"/>
<gfe:replicated-region id="xyz" ignore-if-exists="true"/>
</beans>
Expectation is when the Spring Boot app terminates, Region should be created in the cluster.

Answer 1

The simplest approach here would be to use Cluster Configuration Service, and create regions via gfsh. See the below link for more information
https://docs.spring.io/spring-gemfire/docs/current/reference/html/#bootstrap:cache:advanced
See the section
Using Cluster-based Configuration
For more information on Cluster configuration please see the below link
http://gemfire.docs.pivotal.io/97/geode/configuring/cluster_config/gfsh_persist.html
The your client code probably be a simple gemfire client connecting to the gemfire cluster.

Answer 2

Your expectations are not correct. This is not a limitation with Spring per say, but is a side effect of how GemFire works.
If you were to configure a GemFire peer cache instance/member of the cluster using the GemFire API or pure cache.xml, then the cluster would not "remember" the configuration either.
When using the GemFire API, cache.xml or Spring config (either Spring XML or JavaConfig), the configuration is local to the member. Before GemFire's Cluster Configuration Service, administrators would need to distribute the configuration (e.g. cache.xml) across all the peer members that would form a cluster.
Then along came the Cluster Configuration Service, which enabled users to define their configuration using Gfsh. In Spring config, when configuring/bootstrapping a peer cache member of the cluster, you can enable the use of cluster configuration to configure the member, for example:
<gfe:cache use-cluster-configuration="true" ... />
As was pointed out here (bullet 4).
However, using Gfsh to configure each and every GemFire object (Regions, Indexes, DiskStores, etc) can be quite tedious, especially if you have a lot of Regions. Plus, not all developer want to use a shell tool. Some development teams want to version the config along with the app, which makes good sense.
Given you are using Spring Boot, you should have a look at Spring Boot for Pivotal GemFire, here.
Another way to start your cluster is to configure and bootstrap the members using Spring, rather than Gfsh. I have example of this here. You can, of course, run the Spring Boot app from the command-line using a Spring Boot FAT JAR.
Of course, some administrators/operators prevent development teams from bootstrapping the GemFire cluster in this manner and instead expect the teams to use the tools (e.g. Gfsh) provided by the database.
If this is your case, then it might be better to develop Spring Boot, GemFire ClientCache applications connecting to a standalone cluster that was started using Gfsh.
You can still do very minimal config, such as:
start locator --name=LocatorOne
start server --name=ServerOne
start server --name=ServerTwo
...
And then let your Spring Boot, client application drive the configuration (i.e. Regions, Indexes, etc) of the cluster using SDG's cluster configuration push feature.
There are many different options, so the choice is yours. You need to decide which is best for your needs.
Hope this helps.