已触发WSO2 EMM关闭钩子

Question

我已经成功地使用JDK7在Linux上安装了WSO2 EMM。

应用程序运行正常，但服务器关闭了。在日志文件中，我发现了以下信息：

TID: [0] [EMM] [2015-10-09 10:03:18,044]  INFO {org.wso2.carbon.core.init.CarbonServerManager} -  Shutdown hook triggered....
TID: [0] [EMM] [2015-10-09 10:03:18,045]  INFO {org.wso2.carbon.core.init.CarbonServerManager} -  Gracefully shutting down WSO2 Enterprise Mobile Platform...
TID: [0] [EMM] [2015-10-09 10:03:18,047]  INFO {org.wso2.carbon.core.ServerManagement} -  Starting to switch to maintenance mode...
TID: [0] [EMM] [2015-10-09 10:03:18,047]  INFO {org.wso2.carbon.core.ServerManagement} -  Stopped all transport listeners
TID: [0] [EMM] [2015-10-09 10:03:18,047]  INFO {org.wso2.carbon.core.ServerManagement} -  Waiting for request service completion...
TID: [0] [EMM] [2015-10-09 10:03:18,051]  INFO {org.wso2.carbon.core.ServerManagement} -  All requests have been served.
TID: [0] [EMM] [2015-10-09 10:03:18,051]  INFO {org.wso2.carbon.core.ServerManagement} -  Waiting for deployment completion...
TID: [0] [EMM] [2015-10-09 10:03:18,057]  INFO {org.springframework.web.context.support.XmlWebApplicationContext} - Closing Root WebApplicationContext: startup date [Fri Oct 09 09:59:43 CEST 2015]; root of context hierarchy
TID: [0] [EMM] [2015-10-09 10:03:18,058]  INFO {org.springframework.beans.factory.support.DefaultListableBeanFactory} -  Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@24350e35:defining beans .....

下面是上面的日志，其中只包含消息：

Shutdown hook triggered....
Gracefully shutting down WSO2 Enterprise Mobile Platform...
Starting to switch to maintenance mode...
Stopped all transport listeners
Waiting for request service completion...
All requests have been served.
Waiting for deployment completion...
Closing Root WebApplicationContext: startup date [Fri Oct 09 09:59:43 CEST 2015]; root of context hierarchy
Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@24350e35:defining beans .....

如何关闭carbon服务器的关机触发器？非常感谢。

Answer 1

在Kubernetes环境中，我发现重启容器的是livenessProbe/readinessProbe。您可以通过查看Pod的事件来看到这一点，尽管您只会看到一条关于失败的健康检查的消息(而不是像人们预期的那样，每次重新启动都会看到一条消息)。增加initialDelaySeconds为我解决了这个问题。