Hadoop Common
  1. Hadoop Common
  2. HADOOP-4953

config property mapred.child.java.opts has maximum length that generates NoClassDefFoundError if exceeded

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 0.19.0
    • Fix Version/s: None
    • Component/s: conf
    • Labels:
      None
    • Environment:

      Description

      There is an unexpected max length for the value of config property mapred.child.java.opts that, if exceeded, generates an opaque NoClassDefFoundError in child tasks.

      The max length for the value is 146 chars. A length of 147 chars will cause the exception. For example, adding a single extra space between options will convert a working jvm opts clause into one that always generates NoClassDefFoundError when tasktrackers exec child tasks.

      As laboriously diagnosed, conf/hadoop-site.xml was used to set the property and runs were done on "Amazon EC2 Ubuntu 8.04 hardy AMI" (Debian version "lenny/sid") using java 1.6.0_07-b06. Multiple slaves nodes were used and after conf changes, stop-all.sh and start-all.sh were run before each test. The job config props as found on the slave did not appear to have a truncated or damaged value. It made no difference whether @taskid@ appeared at the end or middle of the options and absence of @taskid@ did not eliminate the problem.

      This bug wastes considerable time because the error looks like a classpath problem and even after the java opts property is suspected, a character quoting or unsupported option seems more likely than a length limit.

        Activity

        Hide
        Allen Wittenauer added a comment -

        I'm closing this as won't fix since this parameter is mostly deprecated in lieu of map and reduce specific environment vars.

        Show
        Allen Wittenauer added a comment - I'm closing this as won't fix since this parameter is mostly deprecated in lieu of map and reduce specific environment vars.
        Hide
        Paul Baclace added a comment -

        I added details of the environment in which this bug occurs. This bug is not intermittent, it is easily reproduced.

        Perhaps the most unusual thing about the runtime env is that Xen virtualization is involved. The host OS seems to be fc8xen with the guest OS Ubuntu (Debian).

        Show
        Paul Baclace added a comment - I added details of the environment in which this bug occurs. This bug is not intermittent, it is easily reproduced. Perhaps the most unusual thing about the runtime env is that Xen virtualization is involved. The host OS seems to be fc8xen with the guest OS Ubuntu (Debian).
        Hide
        Steve Loughran added a comment -

        There's no checking for limits in the code; the configuration is got, expanded, @taskid@ replaced and then split on spaces.

        If something is happening here it may be related to command line length rather than java opt parsing. A quick trace shows that no attempt is made to glue together a string from the parsed pieces; the array is passed as is down to Sun's ProcessBuilder class; if something is playing up there which is not impossible then that's a serious problem

        Paul, you'll have to do some research to see how replicable this is, include OS/JVM info in the bug report. If a test can replicate this, then it can be fixed.

        Show
        Steve Loughran added a comment - There's no checking for limits in the code; the configuration is got, expanded, @taskid@ replaced and then split on spaces. If something is happening here it may be related to command line length rather than java opt parsing. A quick trace shows that no attempt is made to glue together a string from the parsed pieces; the array is passed as is down to Sun's ProcessBuilder class; if something is playing up there which is not impossible then that's a serious problem Paul, you'll have to do some research to see how replicable this is, include OS/JVM info in the bug report. If a test can replicate this, then it can be fixed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Baclace
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development