jboss - WARN [org.jgroups.protocols.TCP] (OOB-19,null) null : no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, 丢弃消息

Question

JBoss中出现如下WARN msg是什么意思，如何解决？我们有一个域模式下的双节点 Jboss EAP 6.0 集群:

[Server:gmailarchivalserverA] 01:18:17,384 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，丢弃消息[Server:gmailarchivalserverA] 01:19:36,183 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，丢弃消息[Server:gmailarchivalserverA] 01:20:50,474 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，丢弃消息[Server:gmailarchivalserverA] 01:21:49,521 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，删除消息[Server:gmailarchivalserverA] 01:22:58,527 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，删除消息[Server:gmailarchivalserverA] 01:24:12,268 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: 445c1d76-9ba6-0cd0-d272-5af596f4d14a 没有物理地址，丢弃消息

Answer 1

对于人们如何调查那个问题，我花了一些时间搜索，我发现了一些要素:

如果您已经尝试过:

• “-b x.x.x.x”(在 jboss 中)https://community.jboss.org/thread/205733
• -Djava.net.preferIPv4Stack=true
• 确保在 TCPPING.initial_hosts JGRP-925 https://issues.jboss.org/browse/JGRP-925 中列出所有节点
• JGRP-1422 https://issues.jboss.org/browse/JGRP-1422
• -Djgroups.bind_addr=

看看来自 jgroups 用户论坛的讨论，其中 Bela Ban 对问题做出了 react (Bela Ban 是 JGroups 项目的首席开发人员，用于 JBoss 应用程序服务器和 Infinispan 中的集群。设计并实现了 JBossCache(Infinispan 的前身):

" I've had a problem ~2 years ago when observing various "no physical address" messaged in the logs; we where running an Infinispan cluster just fine for some time but occasionally the coordinator would start having various problems communicating with the others. I tried to figure out what could be wrong by debugging the JGroups code, but it seems this physical address was being cached by JGroups but otherwise just retrieved from the networking stack.. apparently some times the stack wouldn't be able to return the physical address, but most of the time it wouldn't be a critical problem as JGroups would have it cached. Why the network stack wouldn't return it was beyond my comprehension so I turned for help to a system admin experienced with tuning kernel network modules and he told me one of the network (physical) devices was faulty: we removed the server from the group and I never saw this problem again.

Maybe you can narrow it down to a single server behaving like this"

完整讨论请参阅 http://jgroups.1086181.n5.nabble.com/Re-jgroups-users-Join-problems-no-physical-address-tp9518p9828.html

另请阅读该评论:

"We use HyperV virtualization so problem might be there, I'm not sure. Problem usually happens when network interface on virtual machine crashes - if this happens on coordinator node, cluster is usually unjoinable until all nodes are restarted. But in many other cases, it happens when TCP connectivity between all nodes is OK (nodes are interconnected with TCP beside JG cluster) - some messages cannot be delivered, or node cannot join cluster after restart, or cluster is splitted for no apparent reason.

I hope to migrate to 3.3 soon and try to analyze problem better"

在同一个讨论中。

希望对你有帮助