Announcement Announcement Module
No announcement yet.
Why do I need to define java.rmi.server.hostname? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why do I need to define java.rmi.server.hostname?

    Would anyone care to explain to me why I have to put the following in


    to get my RmiServiceExporter beans to bind to the correct NIC on my server?

  • #2
    By default, the host is localhost ( I'm using RmiServiceExporter without problems, just declaring the bean.


    • #3
      what property did you set?

      I tried setting <property name="registryHost" value=""/> but that doesn't work. Which property are you setting in your config?


      • #4
        I just do the following:


          <bean class="org.springframework.remoting.rmi.RmiServiceExporter">
            <property name="serviceName" value="EmprestimoFachada"/>
            <property name="service" ref="emprestimoFachada"/>
            <property name="serviceInterface" value=""/>

          <bean id="emprestimoFachada" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
            <property name="serviceUrl" value="rmi://localhost:1099/EmprestimoFachada"/>
            <property name="serviceInterface" value=""/>


        • #5
          Is your client on the same host as your server?

          By the look of your client's url rmi://localhost, your client on the same host as your server. My client is on a different machine. That's what appears to cause the problem. Spring's "auto-registry" appears to bind to localhost by default (which is kind of daft for a "remoting" system).
          If I specify the registryHost property explicitly, Spring appears to assume you want to use an existing application server's registry (which I don't have in my case as I'm in Tomcat). Setting "alwaysCreateRegistry" to "true" doesn't appear to do what you would expect either. Hmm.


          • #6
            It has nothing to do with Spring, it's how RMI works.

            When you execute an RMI lookup server generates a stub and _hardcodes_ it's own address in it. Stub is then transfered to the client and address generated by the server used for method remoting. The address hardcoded in the stub has nothing to do with an address you used for a lookup. The algorithm used by the server to find it's own address is not very smart and fails to produce a meaningful result in all but trivial network configurations (very often it produces "localhost" so your rmi clients end up sending requests to themselves). That's why, most of the times, it's needed to override the algorithm by setting java.rmi.server.hostname.


            • #7
              Thanks for the explanation.


              • #8
                Let me try to resurrect the old thread.

                My RMI server doesn't know its IP address. Local clients can access it via a LAN IP address while remote clients outside LAN come through the firewall (which implements port forwarding via NAT) and they use the external IP address. Does anybody know if there is a way for the client to update the _hardcoded_ IP address in the client service stub?

                What happens with the remote clients they first successfully establish connection with the RMI server via WAN IP address and standard RMI port (e.g. 1099) however each exported service stub contain LAN IP address. I would like the client to be able to control that IP. Should I look into using reflection to achieve that? I am still scratching my head about how to approach this.