java连接被拒绝错误与spring boot数据geode远程定位器

Question

根据我的问题Apache Geode Web framework，我检查了来自here 的各种弹簧指南和来自here 的弹簧数据geode 样本，并编写了一个简短的弹簧数据geode 应用程序，但它无法连接到远程 GFSH 启动的 Geode 定位器。应用程序类是：

package cm;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.gemfire.config.annotation.ClientCacheApplication;
import org.springframework.data.gemfire.config.annotation.ClientCacheApplication.Locator;
import org.springframework.data.gemfire.config.annotation.EnablePdx;
import org.springframework.data.gemfire.repository.config.EnableGemfireRepositories;

@SpringBootApplication
@ClientCacheApplication(name = "CmWeb", locators = @Locator, subscriptionEnabled = true)
@EnableGemfireRepositories(basePackageClasses= {CmRequest.class})
@EnablePdx
public class CmWeb {

    public static void main(String[] args) {
        SpringApplication.run(CmWeb.class, args);
    }
}

在资源目录application.properties我已经设置了远程定位器：

# Configure the client's connection Pool to the servers in the cluster
spring.data.gemfire.pool.locators=1.2.3.4[10334]

构建并运行应用程序，它会发现定位器（它作为服务器名称返回）

[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : AutoConnectionSource discovered new locators [UAT:10334]

几秒钟后它抛出错误：

[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : locator UAT:10334 is not running.

和

java.net.ConnectException: Connection refused: connect
    at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) ~[na:1.8.0_232]
    at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) ~[na:1.8.0_232]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_232]
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:204) ~[na:1.8.0_232]
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0_232]
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) ~[na:1.8.0_232]
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_232]
    at java.net.Socket.connect(Socket.java:607) ~[na:1.8.0_232]
    at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:958) ~[geode-core-1.9.2.jar:na]
    at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:899) ~[geode-core-1.9.2.jar:na]
    at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:888) ~[geode-core-1.9.2.jar:na]
    at org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:290) ~[geode-core-1.9.2.jar:na]
    at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:184) ~[geode-core-1.9.2.jar:na]
    at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209) [geode-core-1.9.2.jar:na]
    at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199) [geode-core-1.9.2.jar:na]
    at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287) [geode-core-1.9.2.jar:na]
    at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500) [geode-core-1.9.2.jar:na]
    at org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371) [geode-core-1.9.2.jar:na]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_232]
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_232]
    at org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276) [geode-core-1.9.2.jar:na]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_232]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_232]
    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_232]

经过大量调查，我认为是 spring data geode 客户端根据Connecting GemFire using Spring Boot and Spring Data GemFire 期望一个 spring boot geode 服务器，所以我下载了 ListRegionsOnServerFunction jar 并将其部署在 GFSH 服务器上得到相同的结果（没有尚未重新启动服务器...）但这会导致相同的错误情况。

如果 Spring-Data-Gemfire - Unable to contact a Locator service. Operation either timed out or Locator does not exist 我尝试更改 application.properties 来自

spring.data.gemfire.pool.locators=1.2.3.4[10334]

到

spring.gemfire.locators=1.2.3.4[10334]

或其他变体，则应用无法找到远程定位器并抛出：

[Timer-DEFAULT-3] o.a.g.c.c.i.AutoConnectionSourceImpl : locator localhost/127.0.0.1:10334 is not running.

写这个问题我终于找到了How to connect a remote-locator in Geode，也无法从 SPRING 应用程序 PING GFSH 服务器。但是，使用本地构建的 Geode Native Client for Geode v 1.10 可以为远程定位器客户端和各种其他服务和 UI 正确设置服务器绑定地址。我怀疑默认情况下可能会在这个（半内部）网络上禁用 PING。我还禁用了端口 10334、1099、40404 的防火墙规则，以允许所有流量，但仍然出现相同的错误情况。

事实证明，从 Spring Boot 应用程序中重复的 INFO 消息之后连接被拒绝：

[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : updateLocatorInLocatorList changing locator list: loc form: LocatorAddress [socketInetAddress=UAT:10334, hostname=UAT, isIpString=false] ,loc to: UAT:10334
[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : updateLocatorInLocatorList locator list from:[UAT:10334, /1.2.3.4:10334] to: [LocatorAddress [socketInetAddress=UAT:10334, hostname=UAT, isIpString=false], LocatorAddress [socketInetAddress=/1.2.3.4:10334, hostname=1.2.3.4, isIpString=true]]

然后在服务器上运行list clients，实际上已经建立了从Spring Boot应用程序到Geode服务器v 1.10的连接。啊！

这意味着定位器逻辑正在运行，但这并不能解释为什么在第一次连接后出现java.net.ConnectException: Connection refused: connect 错误。有什么想法吗？

Answer 1

关于您的 Spring Boot 应用程序类的 1 个快速说明...

@SpringBootApplication
@ClientCacheApplication(name = "CmWeb", locators = @Locator, subscriptionEnabled = true)
@EnableGemfireRepositories(basePackageClasses= {CmRequest.class})
@EnablePdx
public class CmWeb {

    public static void main(String[] args) {
        SpringApplication.run(CmWeb.class, args);
    }
}

如果您使用的是 Spring Boot for Apache Geode（或 Pivotal GemFire），则以下陈述正确，强烈推荐。

使用 SBDG 时（通过在应用程序类路径上声明正确的 org.springframework.geode:spring-geode-starter 依赖项），您无需显式声明 @ClientCacheApplication、@EnableGemfireRepositories 或 @EnablePdx 注释，因为 SBDG 会自动配置 @默认为 987654328@ 实例，自动配置 SD 存储库，特别是当所有实体类与 Spring Boot 应用程序位于同一包或子包中时，SBDG 也默认自动配置 PDX。

locator = @Locator 仅指定“默认”GemFire/Geode Pool 在通过ClientCacheFactory 配置时应通过定位器连接到集群，在localhost 上使用默认定位器端口10334。因此，这个属性大多是无用的，我会推荐来自 SBDG 的 new @EnableClusterAware 注释（参见 here）。

其他属性可以通过Spring Bootapplication.properties配置，如下：

spring.application.name=CmWeb
spring.data.gemfire.pool.subscription-enabled=true

提示：您可以在单独的“命名”Pools 上配置订阅，甚至通过属性，如果您在应用程序中使用超过 1 个 Pool（连接数），可能会根据工作流将不同的有效负载路由到不同的集群中的“分组”服务器等。

您已经开始在 application.properties 中配置“DEFAULT”Pool...

# Configure the client's connection Pool to the servers in the cluster
spring.data.gemfire.pool.locators=1.2.3.4[10334]

关于...

经过大量调查，我认为是 spring 数据 geode 客户端需要一个 spring boot geode 服务器

不，SDG 根本不希望使用 Spring 配置或引导集群（服务器）。使用 Gfsh 是完全有效的。对于instance。如果ListRegionsOnServerFunction 不可用，则 SDG 会退回到其他方式（由 Gfsh 知道并使用的 GemFire/Geode 本身提供）。

您在 Spring Boot 应用程序日志中看到的所有消息都来自 Geode 本身，即与 Spring 无关。简而言之，FWIW，SDG/SBDG 是围绕 Apache Geode (Pivotal GemFire) API 和 Java 客户端驱动程序的外观。 SDG/SBDG 任由该客户做正确的事情，当然，这部分取决于正确的配置。仍然......我现在真的只是在大声思考，因为我怀疑你已经很清楚（或已经发现）这一切。

我还要说 Java 客户端和 Native Client 也不完全是苹果对苹果的比较。这意味着，如果您在没有 Spring 的情况下仅使用 Apache Geode (Pivotal GemFire) API 开发客户端，您将遇到完全相同的问题。

我从未见过第一个连接建立但后续连接得到“连接被拒绝”的情况，o.O #argh

您是否尝试过与旧版 Geode 相同的配置/安排，例如1.9？

很抱歉给您带来麻烦。我会考虑更多。