12

I use the -Djava.rmi.server.hostname=localhost option to make rmi listen on localhost only, but netstat shows the socket is listening on 0.0.0.0.

The strange thing is that the RMI RenewClean thread shows its using localhost. E.g. RMI RenewClean-[localhost:59357]

I assumed that if I set -Djava.rmi.server.hostname=localhost it should only be listening on 127.0.0.1

Am I misunderstanding what java.rmi.server.hostname controls?

Neil Wightman
  • 1,103
  • 2
  • 9
  • 29
  • 1
    0.0.0.0 is also loop back. Perhaps its getting confused because they are much the same. (I don't know what the difference is) Have you tried `-Djava.rmi.server.hostname=127.0.0.1` – Peter Lawrey Apr 16 '12 at 12:16
  • 1
    @PeterLawrey No. Nothing to do with it. See my answer. – user207421 Apr 16 '12 at 12:42

3 Answers3

23

I assumed that if I set -Djava.rmi.server.hostname=localhost it should only be listening on 127.0.0.1

No.

Am I misunderstanding what java.rmi.server.hostname controls?

Yes. java.rmi.server.hostname has nothing whatsoever to do with what IP address the remote object listens on. That is determined by the RMIServerSocketFactory.

To correct the misquotation from my book in another answer (subsequently deleted):

java.rmi.server.hostname: Hostname string; default value is the local host's IP address in "dotted-quad" format ... which is embedded into remote stubs created by this JVM when remote objects are exported. This can be used to control the effective IP address of RMI servers exported by multi-homed hosts. This property is read exactly once in the life of the JVM.[1]

To expand on that, it can also be used to control the effective IP address (as seen by clients) of RMI servers exported by hosts that are behind NAT devices. It doesn't necessarily have anything to do with the local host, e.g. in NAT situations, and it can be either a hostname, a dotted-quad IPv4 address, or an IPv6 address.

[1] Pitt & McNiff, java.rmi, The Remote Method Invocation Guide, Addison Wesley 2001, p.258.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • TBH I don't quite understand then how it affects configuration at http://stackoverflow.com/a/32418821/241986 - without this line it stops working – Boris Treukhov Sep 06 '15 at 00:35
  • @BorisTreukhov I've answered that. It affects what goes in the stub. Not what IP address it listens at. – user207421 Sep 17 '15 at 12:16
  • @Ser *Non sequitur.* That property doesn't control what IP address the server listens at. Removing it might indeed affect connectivity, but not because it changed the bind-address. – user207421 Sep 04 '19 at 11:07
  • @isapir Yes. I had already answered that five years previously. – user207421 Sep 04 '19 at 11:08
  • @EdwinSamuelJonathan No there isn't, but again this is a *non sequitur.* It doesn't affect the bind-address, which is controlled bye socket factory. This was stated in 2012, seven years before your comment. – user207421 Sep 04 '19 at 11:08
1

Since Java 8u102 -Dcom.sun.management.jmxremote.host binds to the special ip address.

Donald
  • 321
  • 1
  • 2
  • 10
-1

Having run into this issue myself, I wanted to provide a different context to explain what this value is to those that are familiar with how HTTP works. When you initially connect to the port specified by com.sun.management.jmxremote.port, the response is effective the same as an HTTP redirect to the name formed by: java.rmi.server.hostname:com.sun.management.jmxremote.rmi.port. This means that the hostname must be a) resolvable by the JMX client, and b) permitted via routing and firewalls to be connected to. The port can overlap with the initial port that provides the redirect as well however.

Now, the question is: Can you prevent the redirect? As best I can tell, no. I have tried setting the hostname to various values such as 0.0.0.0, 255.255.255.255, '' (empty). I've set the port to "0" as well, to see if this impacts the behavior. Nope. Despite the fact that you CAN connect to the same port for the lookup and the RMI portion of the protocol, it doesn't let you just establish the connections to the same resolved IP.

I assume that this behavior is to allow a process to act as a central index for RMI ports for multiple processes or many nodes of a cluster, but with NAT, it is just an irritating relic of days long past in protocol design.

Erik Brandsberg
  • 99
  • 4