一切看起来都很好,但是一旦它完成了初始化,它就会停止。
@SpringBootApplication
@LocatorApplication
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}日志:
2020-08-03 10:59:18.250 INFO 7712 --- [ main] o.a.g.d.i.InternalLocator : Locator started on 10.25.209.139[8081]
2020-08-03 10:59:18.250 INFO 7712 --- [ main] o.a.g.d.i.InternalLocator : Starting server location for Distribution Locator on LB183054.dmn1.fmr.com[8081]
2020-08-03 10:59:18.383 INFO 7712 --- [ main] c.f.g.l.LocatorSpringApplication : Started LocatorSpringApplication in 8.496 seconds (JVM running for 9.318)
2020-08-03 10:59:18.385 INFO 7712 --- [m shutdown hook] o.a.g.d.i.InternalDistributedSystem : VM is exiting - shutting down distributed system
2020-08-03 10:59:18.395 INFO 7712 --- [m shutdown hook] o.a.g.i.c.GemFireCacheImpl : GemFireCache[id = 1329087972; isClosing = true; isShutDownAll = false; created = Mon Aug 03 10:59:15 EDT 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60]: Now closing.
2020-08-03 10:59:18.416 INFO 7712 --- [m shutdown hook] o.a.g.d.i.ClusterDistributionManager : Shutting down DistributionManager 10.25.209.139(locator1:7712:locator)<ec><v0>:41000.
2020-08-03 10:59:18.517 INFO 7712 --- [m shutdown hook] o.a.g.d.i.ClusterDistributionManager : Now closing distribution for 10.25.209.139(locator1:7712:locator)<ec><v0>:41000
2020-08-03 10:59:18.518 INFO 7712 --- [m shutdown hook] o.a.g.d.i.m.g.Services : Stopping membership services
2020-08-03 10:59:18.518 INFO 7712 --- [ip View Creator] o.a.g.d.i.m.g.Services : View Creator thread is exiting
2020-08-03 10:59:18.520 INFO 7712 --- [Server thread 1] o.a.g.d.i.m.g.Services : GMSHealthMonitor server thread exiting
2020-08-03 10:59:18.536 INFO 7712 --- [m shutdown hook] o.a.g.d.i.ClusterDistributionManager : DistributionManager stopped in 120ms.
2020-08-03 10:59:18.537 INFO 7712 --- [m shutdown hook] o.a.g.d.i.ClusterDistributionManager : Marking DistributionManager 10.25.209.139(locator1:7712:locator)<ec><v0>:41000 as closed.发布于 2020-08-03 19:40:21
是的,这是预期的行为,OOTB。
大多数Apache进程(客户机(即ClientCache)、Locators、管理器和“对等”Cache节点/集群/分布式系统的成员)只创建守护进程线程(即非阻塞线程)。因此,Apache进程将启动、初始化自身,然后立即关闭。
只有Apache CacheServer进程(一个具有侦听客户端连接的CacheServer组件的“对等”Cache )启动并继续运行。这是因为用于侦听客户端Socket连接的Socket是在一个非守护进程线程(即阻塞线程)上创建的,这防止了JVM进程关闭。否则,CacheServer也会直接掉下去。
您可能在想,Gfsh如何防止Locators (即使用start locator命令)和“服务器”(即使用start server命令)关闭?
注意:默认情况下,Gfsh在使用
CacheServer命令启动GemFire/Geode服务器时创建一个start server实例。“服务器”的CacheServer组件可以通过为命令指定--disable-default-server选项来禁用start server。在这种情况下,这个“服务器”将无法服务客户端。尽管如此,对等节点/成员仍将继续运行,但不会没有额外的帮助。有关这里 Gfsh命令的更多细节,请参见start server。
那么,Gfsh如何防止进程失败呢?
在幕后,Gfsh使用LocatorLauncher和ServerLauncher类配置和分叉JVM进程,分别启动Locators和服务器。
例如,这里是Gfsh使用LocatorLauncher类的start locator命令。从技术上讲,它使用从LocatorLauncher类实例到构造 (特别是这里)的配置--用于分叉和发射 (特别是这里)的java命令行--一个单独的JVM进程。
但是,这里的关键是启动LocatorLauncher类时传递给Locator类的特定“命令”,即START命令(这里)。
在LocatorLauncher类中,我们看到START命令执行以下操作,从主要方法到运行方法,它是开始 Locator,然后是waitsOnLocator (使用实现)。
如果没有等待,Locator就会在您正在经历的过程中直线下降。
您可以使用以下代码模拟相同的效果(即“直接通过”),它使用Apache配置和启动一个Locator (进程中)。
public class ApacheGeodeLocatorApplication {
public static void main(String[] args) {
LocatorLauncher locatorLauncher = new LocatorLauncher.Builder()
.set("jmx-manager", "true")
.set("jmx-manager-port", "0")
.set("jmx-manager-start", "true")
.setMemberName("ApacheGeodeBasedLocator")
.setPort(0)
.build();
locatorLauncher.start();
//locatorLauncher.waitOnLocator();
}
}这个简单的小程序会直接通过。但是,如果取消locatorLaucncher.waitOnLocator()注释,那么JVM进程将阻塞。
这与SDG的LocatorFactoryBean类(参见来源)实际上所做的没有什么不同。它也使用LocatorLauncher类来配置和引导进程中的Locator .LocatorFactoryBean是用于在您的Locator类上声明SDG @LocatorApplication注释时配置和引导@SpringBootApplication的类。
不过,我认为在这方面仍有改进的余地。因此,我已经提交了DATAGEODE-361。
同时,作为一种解决方法,您可以通过查看Apache Locator (,SBDG)项目中的烟雾测试来实现阻塞的相同效果。见这里。
但是,在完成DATAGEODE-361之后,防止Locator进程关闭的额外逻辑就不再必要了。
https://stackoverflow.com/questions/63197753
复制相似问题