Hadoop Map/Reduce
  1. Hadoop Map/Reduce
  2. MAPREDUCE-260

control-c of the submitting program should kill the job

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Currently, if you kill the process that submitted the job, the job continues. The default behavior should be to kill the job if the launching process dies.

        Activity

        Hide
        Andrzej Bialecki added a comment -

        I alaways thought this was a feature ... I would sometimes forget to use screen(1), and was extremely grateful that even though I lost my terminal session Hadoop would continue working and complete the job.

        Show
        Andrzej Bialecki added a comment - I alaways thought this was a feature ... I would sometimes forget to use screen(1), and was extremely grateful that even though I lost my terminal session Hadoop would continue working and complete the job.
        Hide
        Doug Cutting added a comment -

        > I always thought this was a feature ...

        Heh. That was my first thought too. But that behaviour is contrary to most command line programs. The use of MapReduce should be transparent and consistent. Control-C should do the same thing regardless of whether LocalRunner or a JobTracker is used. So I'm +1 for this change.

        Show
        Doug Cutting added a comment - > I always thought this was a feature ... Heh. That was my first thought too. But that behaviour is contrary to most command line programs. The use of MapReduce should be transparent and consistent. Control-C should do the same thing regardless of whether LocalRunner or a JobTracker is used. So I'm +1 for this change.
        Hide
        Owen O'Malley added a comment -

        To be honest, I've used it as a feature too, but it confuses users who don't expect that behavior. I will likely leave a config option that retains the current behavior, but I want the default to be the other way.

        Show
        Owen O'Malley added a comment - To be honest, I've used it as a feature too, but it confuses users who don't expect that behavior. I will likely leave a config option that retains the current behavior, but I want the default to be the other way.
        Hide
        Yoram Arnon added a comment -

        wouldn't simply running the command in the background provide the current behavior?

        Show
        Yoram Arnon added a comment - wouldn't simply running the command in the background provide the current behavior?
        Hide
        Milind Bhandarkar added a comment -

        >I will likely leave a config option that retains the current behavior,

        Rather than proliferating config options, I suggest we provide a SyncJobClient, which terminates the job on ctrl-C, and use it in streaming as default. A "--background" option will use the regular JobClient.

        Show
        Milind Bhandarkar added a comment - >I will likely leave a config option that retains the current behavior, Rather than proliferating config options, I suggest we provide a SyncJobClient, which terminates the job on ctrl-C, and use it in streaming as default. A "--background" option will use the regular JobClient.
        Hide
        Owen O'Malley added a comment -

        The problem with command line switches is that not all applications use the ToolBase class, which in my opinion should be reworked into a library rather than a base class. Certainly it makes sense to add a submitBatchJob method or boolean parameter to control the behavior programmatically (not a new class).

        Show
        Owen O'Malley added a comment - The problem with command line switches is that not all applications use the ToolBase class, which in my opinion should be reworked into a library rather than a base class. Certainly it makes sense to add a submitBatchJob method or boolean parameter to control the behavior programmatically (not a new class).
        Hide
        Harsh J added a comment -

        This has settled down as a feature for users now. We should not change this behavior, and I do not see harm in letting it be as-is.

        Show
        Harsh J added a comment - This has settled down as a feature for users now. We should not change this behavior, and I do not see harm in letting it be as-is.

          People

          • Assignee:
            Owen O'Malley
            Reporter:
            Owen O'Malley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development