Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-304

Update NicUtil and the build.xml file to parameterize them for the ethernet interface.

    Details

      Description

      NicUtil and build.xml are effectively hardwired to eth0 with the result that the unit tests can not be run on systems where eth0 is the wrong interface (e.g., eth1, eth2, eth3, ...). For example, this has been observed under Windows Server, but it could affect any platform where eth0 was, for some reason, not an appropriate interface to use for the unit tests.

        Activity

        Hide
        btmurphy btmurphy added a comment -

        Replying to thompsonbry:

        > NicUtil and build.xml are effectively hardwired to eth0 with the result that the unit tests can not be run on systems where eth0 is the wrong interface (e.g., eth1, eth2, eth3, ...).

        This is not a bug. "eth0" is not hardwired in either NicUtil.java
        or build.xml. The only place where eht0 is mentioned in NicUtil
        is in one of the versions of the getInetAddress convenience
        method; the version that allows one to pass in a Configuration,
        and then defaults to eth0 if the given Configuration does
        not specify an entry with the given entry name. Additionally,
        as far as I can tell, that version of getInetAddress is never
        called anywhere in the Bigdata code.

        With respect to this ticket's summary, "Update NicUtil and the
        build.xml file to parameterize them for the ethernet interface",
        it's not clear what sort of "parameterization updates" are being
        asked for; nor is it clear whether the request is related to
        starting a federation using 'bigdata start' in conjunction with
        bigdataCluser(16).config/bigdataStandalone.config, or using build.xml
        to run the tests. In the case of the former, bigdataCluser(16).config/bigdataStandalone.config
        do not currently use NicUtil (they specify explicit IP addresses instead)
        so any changes to NicUtil would have no effect. In the latter case, if
        the request is asking that a system property be set in build.xml, then
        this still does not affect NicUtil; rather, it would be the test related
        configs that would need to be changed.

        [wrote|thompsonbry]:

        > It is LookupStarter on line BLZG-273 which references NicUtil using "eth0".

        The original intent of the LookupStarter class was to provide a
        convenient utility for the build.xml to use to auto-start and
        auto-stop a lookup service that is external to the running of
        the junit tests themselves. It was never intended to be used in
        deployment.

        Unfortunately, at some point, someone moved that class from the test
        area to the bigdata source area. That fact, and the fact that there's
        commented out code that was added to the JiniServicesHelper class that
        references LookupStarter, seems to imply that there's a possible/future
        intent to use that utility in the ServicesManagerService deployment
        mechanism.

        [wrote|thompsonbry]:

        > I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress.

        Adding such a mechanism to NicUtil and then modifying the LookupStarter
        utility to use that mechanism is definitely something to consider;
        especially for development -- rather than deployment -- scenarios.
        In deployment scenarios, although one might imagine that there may
        be some deployment scenarios where it doesn't matter which interface(s)
        the network traffic is sent over, this is typically not the case.
        Generally, one would want to explicitly specify the network interface
        names in a real deployment, and fail fast if one or more of the
        expected/specified interfaces are not available.

        With respect to deploying bigdata -- with either the ServiceManagerService
        mechanism or some other mechanism -- the use of the LookupStarter
        utility for deploying the lookup service should be avoided; and the
        Jini ServiceStarter should instead be used.

        Show
        btmurphy btmurphy added a comment - Replying to thompsonbry : > NicUtil and build.xml are effectively hardwired to eth0 with the result that the unit tests can not be run on systems where eth0 is the wrong interface (e.g., eth1, eth2, eth3, ...). This is not a bug. "eth0" is not hardwired in either NicUtil.java or build.xml. The only place where eht0 is mentioned in NicUtil is in one of the versions of the getInetAddress convenience method; the version that allows one to pass in a Configuration, and then defaults to eth0 if the given Configuration does not specify an entry with the given entry name. Additionally, as far as I can tell, that version of getInetAddress is never called anywhere in the Bigdata code. With respect to this ticket's summary, "Update NicUtil and the build.xml file to parameterize them for the ethernet interface", it's not clear what sort of "parameterization updates" are being asked for; nor is it clear whether the request is related to starting a federation using 'bigdata start' in conjunction with bigdataCluser(16).config/bigdataStandalone.config, or using build.xml to run the tests. In the case of the former, bigdataCluser(16).config/bigdataStandalone.config do not currently use NicUtil (they specify explicit IP addresses instead) so any changes to NicUtil would have no effect. In the latter case, if the request is asking that a system property be set in build.xml, then this still does not affect NicUtil; rather, it would be the test related configs that would need to be changed. [wrote|thompsonbry] : > It is LookupStarter on line BLZG-273 which references NicUtil using "eth0". The original intent of the LookupStarter class was to provide a convenient utility for the build.xml to use to auto-start and auto-stop a lookup service that is external to the running of the junit tests themselves. It was never intended to be used in deployment. Unfortunately, at some point, someone moved that class from the test area to the bigdata source area. That fact, and the fact that there's commented out code that was added to the JiniServicesHelper class that references LookupStarter, seems to imply that there's a possible/future intent to use that utility in the ServicesManagerService deployment mechanism. [wrote|thompsonbry] : > I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress. Adding such a mechanism to NicUtil and then modifying the LookupStarter utility to use that mechanism is definitely something to consider; especially for development -- rather than deployment -- scenarios. In deployment scenarios, although one might imagine that there may be some deployment scenarios where it doesn't matter which interface(s) the network traffic is sent over, this is typically not the case. Generally, one would want to explicitly specify the network interface names in a real deployment, and fail fast if one or more of the expected/specified interfaces are not available. With respect to deploying bigdata -- with either the ServiceManagerService mechanism or some other mechanism -- the use of the LookupStarter utility for deploying the lookup service should be avoided; and the Jini ServiceStarter should instead be used.
        Hide
        bryanthompson bryanthompson added a comment -

        The issue is blocking the ability to run unit tests and benchmarks against a bigdata federation instance running on a single machine using an ethernet interface other than eth0.

        Show
        bryanthompson bryanthompson added a comment - The issue is blocking the ability to run unit tests and benchmarks against a bigdata federation instance running on a single machine using an ethernet interface other than eth0.
        Hide
        btmurphy btmurphy added a comment -

        Changeset 3256

        Verification: used ant to run the tests on both linux and Windows XP; no change in test results.

        Show
        btmurphy btmurphy added a comment - Changeset 3256 Verification: used ant to run the tests on both linux and Windows XP; no change in test results.

          People

          • Assignee:
            btmurphy btmurphy
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: