On 9/1/15 5:47 PM, Arun Gupta wrote:
On Tue, Sep 1, 2015 at 3:33 PM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> Is this scenario different from running multiple WildFly instances on a
> single machine in a non-Docker setup?
Good point, they are the same.
Reading a bit more, it seems Docker gives each container its own
address, visible to the container via the eth0 interface:
https://docs.docker.com/articles/networking/
>
> If not, your choices are to associate each instance with a different
> address, or to use port offsets. If there's only one available address then
> you're down to port offsets.
So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
give the correct address and port?
Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
socket-binding named "http" for the web server, and the web server
address/port is the one you want.
Arun
>
>
> On 9/1/15 4:34 PM, Arun Gupta wrote:
>>
>> Brian,
>>
>> How do you envision this working in a Docker environment?
>>
>> If multiple WildFly containers are running on the same Docker Host
>> (which is going to be common use case), should each WildFly be bound
>> to the IP address of the host?
>>
>> Possibly invoked with a different port offset?
>>
>> Arun
>>
>> On Tue, Sep 1, 2015 at 1:31 PM, Brian Stansberry
>> <brian.stansberry(a)redhat.com> wrote:
>>>
>>> That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which
>>> really is the bound address but AIUI isn't what's wanted.
>>>
>>> If the server is configured to use 0.0.0.0, there is no single
>>> "WildFly.getHostAddress()". That setting means the relevant sockets
will
>>> be listening on all available interfaces on the machine. Which of those
>>> is the one that's useful to a particular client depends on the network
>>> topology.
>>>
>>> BTW, if you know the names of the nics in your target environment but
>>> don't know the addresses, WildFly (and EAP) let you configure the
>>> interfaces to use a particular nic. If binding to 0.0.0.0 is a
>>> workaround for not knowing the actual addresses, that may help. For
>>> example:
>>>
>>> <interface name="public">
>>> <nic name="eth0"/>
>>> </interface>
>>>
>>> The 'name' attribute also allows expressions:
>>>
>>> <nic name="${my.public.nic:eth0}"/>
>>>
>>> With that kind of config, the JMX query Filippe showed will provide a
>>> regular address.
>>>
>>> [1] The CLI op:
>>>
>>> [standalone@localhost:9990 /]
>>>
>>>
/socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
>>> {
>>> "outcome" => "success",
>>> "result" => "0.0.0.0"
>>> }
>>>
>>> On 9/1/15 12:25 PM, Filippe spolti wrote:
>>>>
>>>> Hello Arun,
>>>>
>>>> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly
>>>> 9/10.
>>>>
>>>> MBeanServer mBeanServer =
>>>> ManagementFactory.getPlatformMBeanServer();
>>>> String url = null;
>>>> try {
>>>>
>>>> ObjectName http = new
>>>>
>>>>
ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>>> String jbossHttpAddress = (String)
>>>> mBeanServer.getAttribute(http,"boundAddress");
>>>> int jbossHttpPort = (Integer)
>>>> mBeanServer.getAttribute(http,"boundPort");
>>>> url = jbossHttpAddress + ":" + jbossHttpPort;
>>>> log.fine("Url obtained from the system: " +
url);
>>>> } catch (Exception e) {
>>>> log.severe(e.getStackTrace().toString());
>>>> }
>>>> return url;
>>>>
>>>> regards.
>>>>
>>>>
>>>> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>>>>>
>>>>> Assuming WildFly is bound to all available IP addresses using -b
>>>>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>>>>> the IP address where the server is running?
>>>>>
>>>>> Ideally, I'd like something like:
>>>>>
>>>>> WildFly.getHostAddress()
>>>>> WildFly.getHostPort()
>>>>>
>>>>> It could be running in a Docker container, in AWS, on my local
laptop,
>>>>> in OpenShift, or any where else and would like the IP address to be
>>>>> returned correctly.
>>>>>
>>>>> Suggestions?
>>>>>
>>>>> Arun
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat