Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-1143

Initializing a Remoting connection unnecessarily involves DNS server

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Critical Critical
    • None
    • 7.0.0.DR10
    • None
    • Workaround Exists
    • Hide
      • Bind the server to a loopback address or, if you need to use a particular IP address, add a mapping for it into /etc/hosts
      • or configure the SERVER_NAME property for your affected remoting connectors
      Show
      Bind the server to a loopback address or, if you need to use a particular IP address, add a mapping for it into /etc/hosts or configure the SERVER_NAME property for your affected remoting connectors

      Look at this line:
      https://github.com/jboss-remoting/jboss-remoting/blob/4.0.14.Final/src/main/java/org/jboss/remoting3/remote/ServerConnectionOpenListener.java#L100

      This means that is no serverName is configured, creating a new Remoting connection always involves using a DNS server (InetServerAddress.getHostName()). This comes with a visible performance penalty - the handshake takes up to 200 milliseconds more than it needs to. Furthermore, we are observing an obscure bug which causes InetServerAddress.getHostName() sometimes take much more time than usual - around 5 seconds, which is enough to cause a connection timeout in some cases, eg. in the default settings of WildFly test suite, making some tests intermittently fail.

      In case that no serverName is configured, the host name should be obtained only once and then re-used.

      This performance penalty doesn't apply if the server is bound to a loopback address or to an address mapped within /etc/hosts - in that case, DNS is not involved and the initialization is fast.

            dlloyd@redhat.com David Lloyd
            jmartisk@redhat.com Jan Martiska
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: