Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.11
    • Fix Version/s: None
    • Component/s: Java Tests
    • Environment:

      Solaris/Hudson

      Description

      Andrew K noticed whilst setting up Qpid under Hudson that the JMX tests fail under Hudson on Solaris.

      The first error was:

      https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testJMXManagementConsoleConnection/

      java.net.MalformedURLException: Bad URL path: _solaris:30099/jndi/rmi://hudson_solaris:29999/jmxrmi
      

      followed by many instances of:

      https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testConnectionCloseViaManagement/

      internal error: ObjID already in use
      

      The full list of test failures is recorded here:

      https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/#showFailuresLink

      I tried the test cases standalone under OpenSolaris 11 and could not reproduce the problem.

      However, I notice that the initial error looks very much like the issue discussed here:

      http://apache-qpid-users.2158936.n2.nabble.com/Run-qpid-0-6-broker-error-in-Linux-td5517015.html

      Is the problem just being caused by the hostname on the Solaris host in the Jenkins build farm?

        Activity

        Hide
        Keith Wall added a comment -

        builds@apache.org have fixed the hostname problem and this has resolved this issue. No change required to Qpid codebase.

        Show
        Keith Wall added a comment - builds@apache.org have fixed the hostname problem and this has resolved this issue. No change required to Qpid codebase.
        Hide
        Keith Wall added a comment -

        Setting -Djava.rmi.server.hostname=localhost does not work around this problem.

        JMXManagedObjectRegistry manually builds an external JMX service URL using the value returned from InetAddress.getLocalHost().getHostName(). On the (Jenkins Solaris) box with the illegal hostname, the resulting URL is illegal and fails its own validation (method (JMXServiceURL#validate()). java.rmi.server.hostname is not considered.

        It seems to me that it would be a useful enhancement if JMXManagedObjectRegistry used the contents of java.rmi.server.hostname when building the external URL and only fell back to getHostName() when unavailable. But the internal url should continue to use InetAddress.getLocalHost().getHostName() (so would still fail with illegal hostnames).

        I think we should pursue getting the Solaris hostname corrected. Is an email to the APache infrastructure list best?

        Show
        Keith Wall added a comment - Setting -Djava.rmi.server.hostname=localhost does not work around this problem. JMXManagedObjectRegistry manually builds an external JMX service URL using the value returned from InetAddress.getLocalHost().getHostName(). On the (Jenkins Solaris) box with the illegal hostname, the resulting URL is illegal and fails its own validation (method (JMXServiceURL#validate()). java.rmi.server.hostname is not considered. It seems to me that it would be a useful enhancement if JMXManagedObjectRegistry used the contents of java.rmi.server.hostname when building the external URL and only fell back to getHostName() when unavailable. But the internal url should continue to use InetAddress.getLocalHost().getHostName() (so would still fail with illegal hostnames). I think we should pursue getting the Solaris hostname corrected. Is an email to the APache infrastructure list best?
        Hide
        Robbie Gemmell added a comment -

        The hostname does appear to be the cause of the failures, yes. This will probably warrant discussion with infra to have the hostname made legal on the boxes.

        Show
        Robbie Gemmell added a comment - The hostname does appear to be the cause of the failures, yes. This will probably warrant discussion with infra to have the hostname made legal on the boxes.

          People

          • Assignee:
            Keith Wall
            Reporter:
            Keith Wall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development