You are viewing a plain text version of this content. The canonical link for it is here.

Posted to common-dev@hadoop.apache.org by "Devaraj Das (JIRA)" <ji...@apache.org> on 2007/04/10 08:38:32 UTC

[jira] Created: (HADOOP-1235) Progress-report RPCs should wait for the RPC to complete before sending another progress report

Progress-report RPCs should wait for the RPC to complete before sending another progress report
-----------------------------------------------------------------------------------------------

                 Key: HADOOP-1235
                 URL: https://issues.apache.org/jira/browse/HADOOP-1235
             Project: Hadoop
          Issue Type: Bug
          Components: dfs, mapred
            Reporter: Devaraj Das
            Priority: Minor


The Progress-report IPCs don't wait for an invoked IPC to complete before sending another progress report. Since in the IPC server, handlers execute as threads, an old progress report might overwrite the status sent by a newer progress report. Making the progress report IPC methods return a boolean or something, and having the clients wait for the response to a progress report before sending the next one, should handle the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (HADOOP-1235) Progress-report RPC clients should wait for the RPC to complete before sending another progress report

Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.

    [ https://issues.apache.org/jira/browse/HADOOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487810 ] 

Doug Cutting commented on HADOOP-1235:
--------------------------------------

> then we can probably do away with pings from Tasks to the TaskTracker?

Yes, I think so.  The ping thread was required since progress was not reported from a separate thread, and hence was not reliable.  But with progress reports now sent from a separate thread, it should be possible to combine them with pings.  In case it's not obvious, the primary purpose of pings is to make sure that child processes die promptly when their parent dies, when their job is terminated, etc.

> Progress-report RPC clients should wait for the RPC to complete before sending another progress report
> ------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-1235
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1235
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs, mapred
>            Reporter: Devaraj Das
>            Priority: Minor
>
> The Progress-report IPC clients don't wait for an invoked IPC to complete before sending another progress report. Since in the IPC server, handlers execute as threads, an old progress report might overwrite the status sent by a newer progress report. Making the progress report IPC methods return a boolean or something, and having the clients wait for the response to a progress report before sending the next one, should handle the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (HADOOP-1235) Progress-report RPC clients should wait for the RPC to complete before sending another progress report

Posted by "Devaraj Das (JIRA)" <ji...@apache.org>.

     [ https://issues.apache.org/jira/browse/HADOOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Devaraj Das updated HADOOP-1235:
--------------------------------

    Description: The Progress-report IPC clients don't wait for an invoked IPC to complete before sending another progress report. Since in the IPC server, handlers execute as threads, an old progress report might overwrite the status sent by a newer progress report. Making the progress report IPC methods return a boolean or something, and having the clients wait for the response to a progress report before sending the next one, should handle the issue.  (was: The Progress-report IPCs don't wait for an invoked IPC to complete before sending another progress report. Since in the IPC server, handlers execute as threads, an old progress report might overwrite the status sent by a newer progress report. Making the progress report IPC methods return a boolean or something, and having the clients wait for the response to a progress report before sending the next one, should handle the issue.)
        Summary: Progress-report RPC clients should wait for the RPC to complete before sending another progress report  (was: Progress-report RPCs should wait for the RPC to complete before sending another progress report)

If we go down this path and if we have HADOOP-1201 in, then we can probably do away with pings from Tasks to the TaskTracker? ping IPC implementation basically checks for the existence of the taskID string in the tasks map in the TaskTracker & returns a boolean. This check can be done within the progress IPC method equally well.

> Progress-report RPC clients should wait for the RPC to complete before sending another progress report
> ------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-1235
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1235
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs, mapred
>            Reporter: Devaraj Das
>            Priority: Minor
>
> The Progress-report IPC clients don't wait for an invoked IPC to complete before sending another progress report. Since in the IPC server, handlers execute as threads, an old progress report might overwrite the status sent by a newer progress report. Making the progress report IPC methods return a boolean or something, and having the clients wait for the response to a progress report before sending the next one, should handle the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.