Uploaded image for project: 'Hadoop Map/Reduce'
  1. Hadoop Map/Reduce
  2. MAPREDUCE-260

control-c of the submitting program should kill the job

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: 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
        ab 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
        ab 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
        cutting 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
        cutting 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.omalley 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.omalley 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
        yarnon Yoram Arnon added a comment -

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

        Show
        yarnon Yoram Arnon added a comment - wouldn't simply running the command in the background provide the current behavior?
        Hide
        milindb 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
        milindb 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.omalley 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.omalley 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
        qwertymaniac 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
        qwertymaniac 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.omalley Owen O'Malley
            Reporter:
            owen.omalley Owen O'Malley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development