Start-Locator / Locators, which is for client and

2019-05-26 03:39发布

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?

1条回答
走好不送
2楼-- · 2019-05-26 03:59

The Pivotal GemFire locators and start-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 peer Cache [application] node or server. This property is highly convenient when starting a small cluster of GemFire servers (peer member nodes) inside your IDE.

TIP: Typically, in standalone, production environment, you want to startup multiple, separate and dedicated Locator nodes (JVM processes, and usually on different hosts) for resiliency. But during development, using the start-locator property is convenient, especially when testing.

You can read more about the locators and start-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...

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), ...

This will be the case when you have not started a Locator. If you specify start-locator then your Spring (Data for Pivotal GemFire), peer Cache application will embed a Locator (service) on startup, in which case, you do not need to specify the locators 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...

@SpringBootApplication
//@CacheServerApplication(name = "ExampleServerApplication", locators = "localhost[10334]")
@PeerCacheApplication(name = "BookExampleServerApplication", locators = "localhost[10334]")
@EnablePdx(readSerialized = true)
@SuppressWarnings("unused")
public class GeodeServerApplication {

  public static void main(String[] args) {

    new SpringApplicationBuilder(GeodeServerApplication.class)
      .web(WebApplicationType.NONE)
      .build()
      .run(args);
  }

  @Profile("locator-manager")
  @Configuration
  @EnableLocator
  @EnableManager(start = true)
  static class LocatorManagerConfiguration { }

}

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 peer Cache application node (server). The only difference is, the @CacheServerApplication additionally adds a ServerSocket allowing GemFire ClientCache 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 the start-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 port 10334.

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...

-server -ea -Dspring.profiles.active=locator-manager -Dspring.data.gemfire.name=GeodeServerOne

The next 2 run profiles in my IDE are setup like so...

-server -ea -Dspring.profiles.active=none -Dspring.data.gemfire.name=GeodeServerTwo

-server -ea -Dspring.profiles.active=none -Dspring.data.gemfire.name=GeodeServerThree

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:

$ echo $GEODE_HOME
/Users/jblum/pivdev/apache-geode-1.2.1

$ gfsh
    _________________________     __
   / _____/ ______/ ______/ /____/ /
  / /  __/ /___  /_____  / _____  / 
 / /__/ / ____/  _____/ / /    / /  
/______/_/      /______/_/    /_/    1.2.1

Monitor and Manage Apache Geode

gfsh>connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=10.0.0.121, port=1099] ..
Successfully connected to: [host=10.0.0.121, port=1099]

gfsh>list members
      Name       | Id
---------------- | ---------------------------------------------
GeodeServerOne   | 10.0.0.121(GeodeServerOne:42883)<ec><v0>:1024
GeodeServerTwo   | 10.0.0.121(GeodeServerTwo:42911)<v1>:1025
GeodeServerThree | 10.0.0.121(GeodeServerThree:42913)<v2>:1026

If you had enabled these Spring Boot, Pivotal GemFire peer Cache applications to be CacheServers 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

TIP: The BootExampleApplication is using the new Spring Boot for Apache Geode/Pivotal GemFire (SBDG) project which auto-configures a ClientCache instance, by default, when either spring-geode-starter or, alternatively, spring-gemfire-starter, is on your application's classpath. See the docs for additional details. If this project were not using SBDG, then you would explicitly have to annotate your Spring Boot application class with SDG's @ClientCacheApplication.

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

查看更多
登录 后发表回答