On your client you can set the following two system properties to make sure remoting uses a specific bind address/port:
Can you try this on your client?
Setting the bind address and port on the errant client worked. Any ideas why one machine/client would have this problem? I tried getting those properties on the client and unless I set them, they are null.
Of note, the machine on which the client fails used to host the jboss messaging queues. We made sure we deleted all references to the install, but is it possible the jboss server sets some system properties (environment variables) of which I?m not aware of? This is on a linux system. Thanks again,
Maybe you have two network boards or any routing tables spoiled.
I don't think any property would stale the behavior of these connections (besides these ones to configure the port/host)
As a matter of fact, there are three nics in the machine. Only one is active. Will try removing two and see what happens.
The machine is running Fedora Core 4. I was mistaken, there were only two nics in the machine. After removing one of them, I'm still presented with the same problem: the remoting layer translates this machines address into 127.0.0.1 when creating the socket wrapper!
Clebert, any idea how I could check the routing tables as seen by the remoting/messaging layer. All tests from the command line indicate that the machine is configured correctly.
After further investigation, I've concluded it must have something to do with our machine setup, although I'm at a loss as to how this is happening. Running System.out.println( InetAddress.getLocalHost().toString() ); on the affected machine returns the hostname followed by the loopback adress. All other machines return the hostname followed by their assigned ip addresses. Suggestions? Thanks,
Issue resolved. Bad /etc/hosts file. Thanks for all the help.