I have been configuring Pivotal GemFire like this example:
@Configuration
public class GemfireConfiguration {
@Bean
Properties gemfireProperties() {
Properties gemfireProperties = new Properties();
gemfireProperties.setProperty("name","SpringDataGemFireApplication");
gemfireProperties.setProperty("mcast-port", "0");
gemfireProperties.setProperty("log-level", "config");
return gemfireProperties;
}
@Bean
CacheFactoryBean gemfireCache() {
CacheFactoryBean gemfireCache = new CacheFactoryBean();
gemfireCache.setClose(true);
gemfireCache.setProperties(gemfireProperties());
return gemfireCache;
}
@Bean(name="employee")
LocalRegionFactoryBean<String, Employee> getEmployee(final GemFireCache cache) {
LocalRegionFactoryBean<String, Employee> employeeRegion = new LocalRegionFactoryBean();
employeeRegion.setCache(cache);
employeeRegion.setName("employee");
// ...
return employeeRegion;
}
}
I need to put a Locator "localhost[1099]
", but when a I put:
gemfireProperties.setProperty("locators", "localhost[1099]");
I get an error from Spring saying that the Locator could not be found (more specific is NULL
), but I change the setter with:
gemfireProperties.setProperty("start-locator", "localhost[1099]");
The app runs but I don't know if Spring creates the Locator or what happens. I want to point to localhost[1099]
and with this way I am not sure if it is correct.
I saw many examples but it is still not clear to me which property is for client or server app.
I am working on a REST API with spring-data-gemfire
, gemstone, etc...
Could anyone help me?
The Pivotal GemFire
locators
andstart-locator
properties are used by servers only. Neither property applies to clients.locators
identifies the Locator(s) of the cluster that the new member will use to join as a peer. It has the following format:host1[port1],host2[port2],...,hostN[portN]
.start-locator
is used to start an embedded Locator in a peerCache
[application] node or server. This property is highly convenient when starting a small cluster of GemFire servers (peer member nodes) inside your IDE.You can read more about the
locators
andstart-locator
properties here. You can read more about Locators, and specifically member discovery, here and here.So, first question, why do you need a Locator or Locators in this instance?
Regarding...
This will be the case when you have not started a Locator. If you specify
start-locator
then your Spring (Data for Pivotal GemFire), peerCache
application will embed a Locator (service) on startup, in which case, you do not need to specify thelocators
property since it would be redundant.With an embedded Locator, you can then start, or have other members join this member in a cluster.
For example, I often use classes like this to start a small Pivotal GemFire cluster for development, testing and demonstration purposes...
Full source code is available here.
A few things to note.
First, the
@CacheServerApplication
and@PeerCacheApplication
annotations are nearly synonymous. They both create a Spring Boot, Pivotal GemFire peerCache
application node (server). The only difference is, the@CacheServerApplication
additionally adds aServerSocket
allowing GemFireClientCache
based applications (i.e. a Spring Boot application annotated with SDG's@ClientClientApplication
) to connect to the server.As you can see, I have created an inner, static
LocatorManagerConfiguration
class. This class is annotated with@EnableLocator
and@EnableManager
.@EnableLocator
is equivalent to thestart-locator
property and allows you to control the NIC and port to which the embedded Locator service will bind to on startup. By default, the embedded Locator service startups up on "localhost
" bound to the default Locator port10334
.I added the
@EnableManager
annotation to also start the GemFire JMX-based Management service, which allows Gfsh to connect to our Spring Boot configured/bootstrapped GemFire server.I enable this Spring
@Configuration
class with a Spring Profile ("locator-manager
") so that only 1 of the servers starts with the embedded Locator/Manager. Of course, I could have multiple servers start a Locator and/or Manager, but I then need to be careful to vary the port numbers used by the Locator and Manager services when listening for client connections (e.g. the Manager listens for connections from JMX clients like Gfsh, or JConsole, or JVisualVM, etc).So, how do we run this?
Well, let's say we want to create a small GemFire cluster with 3 servers. In my IDE, I create 3 different run profiles using the same
GeodeServerApplication
class. The first run profile will start with the "locator-manager
" Spring profile enabled, like so...The next 2 run profiles in my IDE are setup like so...
The only difference is, for my last run profile, run profile 3, I need to name the server something different, like "
GeodeServerThree
". Pivotal GemFire expects the names of the peer members in the cluster to be unique.Now, from my IDE, I can start the server with the Locator/Manager enabled first, and then run the last 2 servers without the embedded Locator/Manager enabled, next. Then, I can inspect my cluster using Gfsh, as follows:
If you had enabled these Spring Boot, Pivotal GemFire peer
Cache
applications to beCacheServers
as well (by replacing the@PeerCacheApplication
annotation with@CacheServerApplication
), then you would be able to connect a cache client app, similar to the following...https://github.com/jxblum/contacts-application/blob/master/boot-example/src/main/java/example/app/geode/cache/client/BootExampleApplication.java
Read this chapter & section of the SDG Reference Guide for more details.
Anyway, I hope this gives you some guidance into what these properties are for and the power of SDG's annotations. Also have a look at the new Spring Boot for Apache Geode/Pivotal GemFire project (see blog post), which uses convention over configuration with Spring Boot's auto-configuration support to simplify configuring and bootstrapping either client or server Apache Geode/Pivotal GemFire applications further.
Cheers, -John