I think you're hitting one of the problems with RMI on multi-homed machines,
the stubs hold a liveref object which contains an address and a port. On a
machine with multiple addresses you sometimes endup shipping a stub that
contains an address on the "wrong" interface. Take for example my setup
where I have a machine called "fw" (for the obvious reason) which has
two eth interfaces (eth0 = 10.0.0.1 and eth1 = 24.x.x.x dhcp assigned).
the sequence is that the rmiregistry binds 0.0.0.0:1099 (all interfaces,
fixed port) then the server process binds either 10.0.0.1:0 (asks for a
random port from opsys) *or* 24.x.x.x:0 (again random port) and exports all
it's objects on that endpoint (address/port combo). When it binds an object
into the registry the stub is stored in the registry, it contains three
pieces of identifying information: address, port, and object id. When this
info is handed to a client on the same machine you're OK, but when this stub
is handed to remote clients then they don't know how to reach the object.
In my case the server was exporting on the external address so I simply
had to define a route from the internal interface to the external address.
Now when we hit this at work it was the opposite case, the address chosen
was the internal address... which meant no one could reach the server from
outside the firewall (which no one thought to test untill the last #$%@#
minute of course!). "Fortunately" we were on NT and it is trivial to change
the binding order on NT (as in any nt admin could point-click-grunt their
way through it) but, I can't figure out how to do this on Linux. What you're
seeing is similar, except that instead of an external interface it's the
loopback interface that's being bound for the rmi server.
to your questions:
1. yes. this isn't a linux problem perse... rmi is borked in this regard,
the difficulty I see in configuring this aspect of linux doesn't help.
I routinely have several servers up and running in a cooperative
network, all linux boxen clients on several machines talking to all
of the servers - of course in this case each box has exactly ONE
interface, eth0....
2. if you can get it to bind your network interface instead you'll be good
to go.
3. it's sun confidential material, sign the contract and you can see it if
you want... it ain't pretty - trust me.
cabbey at home dot net <*> http://members.home.net/cabbey
I want a binary interface to the brain!
Today's opto-mechanical digital interfaces are just too slow!
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
