What you need to do is add another interface config not bound to
IN_ADDR_ANY and change the jgroups socket binding configs to use that.
The interface address ends up configuring the JGroups UDP.bind_addr
value, and JGroups will not accept 0.0.0.0 for that, since it uses that
parameter to determine the interface on which to *send* datagrams.
If you want the UDP transport to use all available interfaces to receive
multicast messages, set the "receive_on_all_interfaces" param to
in the UDP part of the JGroups subsystem config.
On 12/17/14, 12:05 PM, Wolf-Dieter Fink wrote:
I'm not sure how to handle the "-b 0.0.0.0"
This mean the "public" default interface is bound to ANY and this is
used for jgroups bindings as well.
From former versions the expectation is that either invocations
(remoting http) or clustering (JGroups) works and it is possible to use
other clients or nodes at localhost or connect via the real IP.
I glanced over the docs but did not found a hint what the recommended
way is here.
On 16/12/14 21:58, Tomaž Cerar wrote:
> On Tue, Dec 16, 2014 at 5:20 PM, Wolf-Dieter Fink <wfink(a)redhat.com
> <mailto:firstname.lastname@example.org>> wrote:
> java.net.BindException: [UDP] /0.0.0.0 <http://0.0.0.0>
is not a
> valid address on any
> local network interface
> Mac OSX? if so that is known mac os/jdk limitation.
==> no Fedora
> The url stuff looks like a bug, non resolved expression is passed
> over. Can you create jira for that.
wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat