0

我们的设置是：Glassfish 版本 3.1.2.2 -

  1. DAS 和 instance-1 在同一台机器上运行，而 instance-2 与配置节点在同一网络中的另一台机器上运行。
  2. 我们已根据 Glassfish 高可用性指南在共享目录中设置事务日志：http: //docs.oracle.com/cd/E18930_01/html/821-2416/gjjpy.html#gaxim
  3. 我们使用单播配置进行集群通信，因为我们的网络负载均衡器在网络中以多播模式运行。
  4. 我们的应用程序（.ear 包含多个 .war）有 2 个持久定时器（因为集群中的每个定时器一次只需要一个实例）。

当instance-1（或instance-2）正常关闭时，另一个实例按预期从关闭的实例中恢复定时器。当实例 2 崩溃或异常下线时，实例 1 会恢复其计时器（再次如预期）。但是当实例 1 崩溃时，实例 2 似乎并没有按预期恢复其计时器。

据我从日志中可以看出，instance-2 收到了 instance-1 的正确故障转移消息并开始恢复，但在没有恢复失败实例的任何事务或计时器的情况下完成了它。

谁能告诉我可能是什么问题？（我应该提供更多信息吗？）

4

1 回答 1

0

经过2周左右的工作，我们终于找到了问题所在。

似乎当集群中的一个实例宕机时，恢复实例通过尝试访问宕机实例的“node-host”：“admin-node-port”来检查该实例是否仍在运行。如果您在 DAS 上使用标准创建的节点（就像我们一样），节点主机设置为“localhost”（就像实例 1 所做的那样）。

因此，instance-2 试图通过尝试连接到“localhost”而不是“instance-1-ip”来查看 instance-1 是否已关闭。由于它可以连接到 localhost，因此 instance-1 被错误地标记为正在运行，并且恢复没有继续进行。

我们必须更改域 config.xml 中 instance-1 节点的节点主机来解决此问题，因为无法通过 asadmin 或管理控制台更改默认 localhost- 的配置。

于 2013-01-24T18:17:18.373 回答