[jboss-jira] [JBoss JIRA] Resolved: (AS7-1513) PING incorrectly populated with bind_addr property

PING incorrectly populated with bind_addr property -------------------------------------------------- Key: AS7-1513 URL: https://issues.jboss.org/browse/AS7-1513 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.0.0.Final Reporter: Galder Zamarreño Assignee: Paul Ferraro Fix For: 7.0.1.Final Starting pristine EDG trunk throws: {code}Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=127.0.0.1} at org.jgroups.stack.Configurator.createLayer(Configurator.java:460) at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534) at org.jgroups.JChannel.init(JChannel.java:1725) ... 30 more{code} Full stacktrace in https://gist.github.com/1139341 The problem is with the following piece of code in JChannelFactory: {code} for (ProtocolConfiguration protocol: this.configuration.getProtocols()) { config = this.createProtocol(protocol); binding = protocol.getSocketBinding(); if (binding != null) { this.configureBindAddress(protocol, config, binding); this.configureServerSocket(protocol, config, "bind_port", binding); this.configureServerSocket(protocol, config, "start_port", binding); this.configureMulticastSocket(protocol, config, "mcast_addr", "mcast_port", binding); } else if (transport.getSocketBinding() != null) { // If no socket-binding was specified, use bind address of transport this.configureBindAddress(protocol, config, transport.getSocketBinding()); } configs.add(config); } {code} In particular, is the "transport.getSocketBinding() != null". Our transport has a socket binding associated to it and so this returns true when inspecting PING protocol. As a result, bind_addr is added to PING which is not right. Not 100% sure what the fix exactly should look like, but you shouldn't set a property on a protocol that does not have it. Not sure either what's triggering this because Michal is doing QE testing without any problems.