What does the following WARN msg in JBoss mean, and how to resolve it? We have a two node Jboss EAP 6.0 cluster in domain mode:
[Server:gmailarchivalserverA] 01:18:17,384 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message [Server:gmailarchivalserverA] 01:19:36,183 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message [Server:gmailarchivalserverA] 01:20:50,474 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message [Server:gmailarchivalserverA] 01:21:49,521 WARN [org.jgroups.protocols.TCP] (OOB-19,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message [Server:gmailarchivalserverA] 01:22:58,527 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message [Server:gmailarchivalserverA] 01:24:12,268 WARN [org.jgroups.protocols.TCP] (OOB-20,null) null: no physical address for 445c1d76-9ba6-0cd0-d272-5af596f4d14a, dropping message
For people how investigate on that issue, I spent a some of time searching, and I found a some elements:
if you already tried :
Have a look at that discussion from jgroups user forum, where Bela Ban react to the problem (Bela Ban is the Lead developer of the JGroups project, used for clustering in the JBoss application server and Infinispan. Designed and implemented JBossCache (predecessor of 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"
Refer to for full discussion http://jgroups.1086181.n5.nabble.com/Re-jgroups-users-Join-problems-no-physical-address-tp9518p9828.html
Read also that comment :
"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"
in same discussion.
Hope it helps