Spring Boot Data Geode Remote Locator的Java连接被拒绝错误


java connection refused error with spring boot data geode remote locator

根据我的问题，Apache Geode Web框架从这里检查了各种弹簧指南，从这里检查了Spring数据geode示例，并编写了一个简短的spring数据geode应用程序，但它无法连接到远程GFSH启动的Geode定位器。 Application类是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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中，我设置了远程定位器：

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

生成并运行该应用程序，它会发现定位器(它将作为服务器名称返回)

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

几秒钟后，它引发错误：

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

和

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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的Connecting GemFire要求使用Spring Boot geode服务器，因此我下载了ListRegionsOnServerFunction jar并将其部署在GFSH服务器上获得了相同的结果(尚未重新启动服务器...)，但这会导致相同的错误情况。

如果使用Spring-Data-Gemfire-无法联系定位器服务。操作超时或定位器不存在，我尝试从以下位置更改application.properties

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

至

1
spring.gemfire.locators=1.2.3.4[10334]

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

1
[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 v 1.10的Geode Native Client进行UI连接。我怀疑默认情况下，此(半内部)网络可能会禁用PING。我还禁用了端口10334、1099、40404的防火墙规则，以允许所有流量，但仍然会遇到相同的错误情况。

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

1
2
[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错误。有任何想法吗？

关于您的Spring Boot应用程序类的简要说明...

1
2
3
4
5
6
7
8
9
10
@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用于Apache Geode(或Pivotal GemFire)，则以下陈述是正确的。

使用SBDG时(通过在应用程序类路径上声明正确的org.springframework.geode:spring-geode-starter依赖项)，则无需显式声明@ClientCacheApplication，@EnableGemfireRepositories或@EnablePdx批注，因为SBDG可自动配置ClientCache实例默认情况下，自动配置SD存储库，尤其是当所有实体类与Spring Boot应用程序位于同一软件包或子软件包中时，并且SBDG默认情况下也会自动配置PDX。

locator = @Locator仅指定当通过ClientCacheFactory配置时，"默认" GemFire / Geode Pool应该使用默认定位器端口10334通过localhost上的定位器连接到集群。因此，该属性几乎没有用，我建议使用SBDG的新@EnableClusterAware批注(请参见此处)。

其他属性可以通过Spring Boot application.properties进行配置，如下所示：

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

TIP: You can configure subscription on individually"named" Pools, even via properties, if you are using more than 1 Pool (of connections) in your application, perhaps to route different payloads based on workflows to different"grouped" servers in your cluster, etc.

您已经开始在application.properties中使用以下命令配置" DEFAULT" Pool：

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

关于...

After a lot of investigation I thought it was that the spring data geode client expects a spring boot geode server

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

您在Spring Boot应用日志中看到的所有消息均来自Geode本身，即与Spring无关。简而言之，FWIW，SDG / SBDG是围绕Apache Geode(关键GemFire)API和Java客户端驱动程序的外观。 SDG / SBDG受此客户端的约束，只能做正确的事情，这当然部分取决于正确的配置。仍然……我真的只是想大声一点，因为我怀疑您已经充分意识到(或发现)了所有这一切。

我还要说Java客户端和Native Client也不完全是Apple与Apple的比较。意思是，如果您仅使用不带Spring的Apache Geode(Pivotal GemFire)API开发了一个客户端，那么您将遇到完全相同的问题。

我从未见过建立第一个连接，但随后的连接却收到"连接被拒绝"的情况，o #Ogh

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

麻烦您了我会考虑更多。

相关讨论