时间戳

首页 > 解决方案 > java连接被拒绝错误与spring boot数据geode远程定位器

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

问题描述

根据我的问题Apache Geode Web 框架，我从这里检查了各种弹簧指南和从这里开始的弹簧数据 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 客户端根据使用 Spring Boot 和 Spring Data GemFire 连接 GemFire需要一个 Spring Boot Geode 服务器，因此我下载了 ListRegionsOnServerFunction jar 并将其部署在 GFSH 服务器上得到相同的结果（尚未重新启动服务器......）但这会导致相同的错误情况。

如果通过Spring-Data-Gemfire - 无法联系定位器服务。操作超时或定位器不存在我尝试更改 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.

写了这个问题，我终于找到了如何在 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错误。有任何想法吗？

标签： geodespring-data-gemfire

解决方案

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

@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您不需要显式声明与 Spring Boot 应用程序相同的包或子包，SBDG 默认也自动配置 PDX。@ClientCacheApplication@EnableGemfireRepositories@EnablePdxClientCache

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

其他属性可以通过 Spring Boot 配置application.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 data geode客户端需要一个spring boot geode服务器

不，SDG 根本不希望使用 Spring 配置或引导集群（服务器）。使用 Gfsh 是完全有效的。例如. _ 如果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 开发客户端，您将遇到完全相同的问题。

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

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

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

推荐阅读