JBoss 7.1.1. bound to 2 ip addresses

[sd_23]

I have a server PC with 2 ethernet card, so it has two IP addresses. A JBoss 7.1.1 is running on this server PC. I bound the JBoss to 0.0.0.0, because the JBoss has to receive jms messages from the first IP address, but the user interface communicates with it through the second IP address.

set "JAVA_OPTS=%JAVA_OPTS% -Djboss.bind.address=0.0.0.0"

The jms messaging didn't work (couldn't find the queue) unless i set the jboss bind address to the first IP

set "JAVA_OPTS=%JAVA_OPTS% -Djboss.bind.address=192.168.89.253"

But at this time the user can't communicate with the server. How can i configure the JBoss to make the jms work and at the same time the user can reach the server through the second ip with the user interface?

[jbertram]

If the server is listening on multiple interfaces then you will need multiple HornetQ connectors and corresponding connection factories each pointing to the appropriate interface.  Since you haven't included your HornetQ configuration I can only assume you haven't configured this already.

[sd_23]

Thanks for your quick answer! Yes, my server is listening on multiple (2) IPs, but i only expect JMS messages from one. My HornetQ configuration is the same as the default. The only difference is that i have a queue:

<jms-destinations>

                    <jms-queue name="stateQueue">

                        <entry name="queue/state"/>

                        <entry name="java:jboss/exported/jms/queue/state"/>

                    </jms-queue>

</jms-destinations>

"...connection factories each pointing to the appropriate interface" - can you give me an example how can i make a jms connection factory pointing to an interface?

[jbertram]

Yes, my server is listening on multiple (2) IPs, but i only expect JMS messages from one.

In that case you would need to re-configure the relevant connector to point to the proper interface.  Here's how the configuration works:

1. JMS client looks up and uses a particular connection factory, e.g. "jms/RemoteConnectionFactory".
2. Said connection factory is configured to use a particular connector, e.g. "netty".
3. The connector is configured with a particular socket-binding, e.g. "messaging".
4. The socket-binding is configured to use a particular interface, e.g. "public".
5. The interface is configured to listen on a particular inet-address, e.g. 0.0.0.0 in your case.

That means in your configuration a JMS client will ultimately try to connect to 0.0.0.0 which, of course, isn't valid for a client.  Therefore you need to configure the connection factory to ultimately use a valid address.

"...connection factories each pointing to the appropriate interface" - can you give me an example how can i make a jms connection factory pointing to an interface?

In your case since you will only be using JMS through one of the NICs I think you should be able to configure a "client-mapping" for the "messaging" socket-binding that references the address the client should use, e.g.:

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

        ...

        <socket-binding name="messaging" port="5445" client-mapping="xxx.xxx.xxx.xxx" />

       ...

    </socket-binding-group>

I'm not positive that HornetQ in JBoss AS 7.1.1.Final supported the "client-mapping" so if that doesn't work then you could upgrade to the latest version of Wildfly (which I recommend anyway since 7.1.1.Final is so old now) or you should be able to add a new interface that corresponds to the NIC and then change the "messaging" socket-binding to use that interface, e.g.:

    <interfaces>

        <interface name="my-interface">

            <inet-address value="xxx.xxx.xxx.xxx"/>

        </interface>

        ...

    </interfaces>

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

        ...

        <socket-binding name="messaging" port="5445" interface="my-interface" />

       ...

    </socket-binding-group>

[sd_23]

Thank you Justin, it worked!