Hadoop Common
  1. Hadoop Common
  2. HADOOP-5353

add progress callback feature to the slow FileUtil operations with ability to cancel the work

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 0.21.0
    • Fix Version/s: None
    • Component/s: fs
    • Labels:
      None

      Description

      This is something only of relevance of people doing front ends to FS operations, and as they could take the code in FSUtil and add something with this feature, its a blocker to none of them.

      Current FileUtil.copy can take a long time to move large files around, but there is no progress indicator to GUIs, or a way to cancel the operation mid-way, j interrupting the thread or closing the filesystem.

      I propose a FileIOProgress interface to the copy ops, one that had a single method to notify listeners of bytes read and written, and the number of files handled.

      
      

      interface FileIOProgress

      { boolean progress(int files, long bytesRead, long bytesWritten); }

      The return value would be true to continue the operation, or false to stop the copy and leave the FS in whatever incomplete state it is in currently.

      it could even be fancier: have beginFileOperation and endFileOperation callbacks to pass in the name of the current file being worked on, though I don't have a personal need for that.

      GUIs could show progress bars and cancel buttons, other tools could use the interface to pass any cancellation notice upstream.

      The FileUtil.copy operations would call this interface (blocking) after every block copy, so the frequency of invocation would depend on block size and network/disk speeds. Which is also why I don't propose having any percentage done indicators; it's too hard to predict percentage of time done for distributed file IO with any degree of accuracy.

        Activity

        Hide
        Lei (Eddy) Xu added a comment -

        Thank you Steve Loughran! Your comments are a great start point for me to adjust this patch!

        I will try to implement a callback to IOProgress now and see what I can get from there..

        Show
        Lei (Eddy) Xu added a comment - Thank you Steve Loughran ! Your comments are a great start point for me to adjust this patch! I will try to implement a callback to IOProgress now and see what I can get from there..
        Hide
        Steve Loughran added a comment -

        well, that was a long time ago, wasn't it?

        Having a quick look at the patch the core design looks good

        • Progress should be IOProgress in case we add more types in future
        • StopProgress should be StopProgressException, and take a text string

        I see in this design a remote listener is expected to poll for status. I'd envisaged some kind of callback instead, but actually a progress counter would be more loosely coupled. Polling can be inefficient, so we should recommend to tools that they do a sleep+poll

        One of the fun things would actually be implementing a cancel operation; most bulk single-thread IO operations don't; the HTTP based object stores do all their work in close() so stopping the write isn't enough...

        Show
        Steve Loughran added a comment - well, that was a long time ago, wasn't it? Having a quick look at the patch the core design looks good Progress should be IOProgress in case we add more types in future StopProgress should be StopProgressException , and take a text string I see in this design a remote listener is expected to poll for status. I'd envisaged some kind of callback instead, but actually a progress counter would be more loosely coupled. Polling can be inefficient, so we should recommend to tools that they do a sleep+poll One of the fun things would actually be implementing a cancel operation; most bulk single-thread IO operations don't; the HTTP based object stores do all their work in close() so stopping the write isn't enough...
        Hide
        Lei (Eddy) Xu added a comment -

        Upload a Progress interface for discussion. I would like to gather some feedbacks before integrating this patch to the current fs.shell.

        I imagine the refactored shell copy command should look like below:

        CopyCommands.java
        class Put extends ... {
        
        private Progress progress = new FileIOProgress();
        
        protected void processArguments(args ...) {
           ...
          try {
             processArguments(args);
          } catch (IOException e) {
             ...
          } catch (interruptedexception e) {
             progress.stop();
          } catch (StopProgress e) {
             LOG.info("Copy operation is stopped.");
          }
            ...
        } 
        

        Steve Loughran, would you take a look at this patch and give some advices?

        Thank you!

        Show
        Lei (Eddy) Xu added a comment - Upload a Progress interface for discussion. I would like to gather some feedbacks before integrating this patch to the current fs.shell . I imagine the refactored shell copy command should look like below: CopyCommands.java class Put extends ... { private Progress progress = new FileIOProgress(); protected void processArguments(args ...) { ... try { processArguments(args); } catch (IOException e) { ... } catch (interruptedexception e) { progress.stop(); } catch (StopProgress e) { LOG.info( "Copy operation is stopped." ); } ... } Steve Loughran , would you take a look at this patch and give some advices? Thank you!

          People

          • Assignee:
            Lei (Eddy) Xu
            Reporter:
            Steve Loughran
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:

              Development