hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11552) Allow handoff on the server side for RPC requests
Date Tue, 15 Nov 2016 21:31:58 GMT

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

Jian He commented on HADOOP-11552:
----------------------------------

looks good to me overall, minor comments:
- rename " updateMetrics(String name, long processingTime) {" to updateDeferredMetrics ?
- Should {{rpcMetrics.addRpcProcessingTime(processingTime);}}  be inside the {{if (!deferredCall)}}
condition, also the {{logSlowRpcCalls}}.
{code}
    rpcMetrics.addRpcQueueTime(queueTime);
    rpcMetrics.addRpcProcessingTime(processingTime);
    if (!deferredCall) {
      rpcDetailedMetrics.addProcessingTime(name, processingTime);
      callQueue.addResponseTime(name, getPriorityLevel(), queueTime,
          processingTime);
    }
    if (isLogSlowRPC()) {
      logSlowRpcCalls(name, processingTime);
    }
{code}
- Add assert.fail after  "BytesWritable response = (BytesWritable) future.get();" ?
{code}
      server.sendError();
      try {
        BytesWritable response = (BytesWritable) future.get();
      } catch (ExecutionException e) {
        Throwable cause = e.getCause();
        Assert.assertTrue(cause instanceof RemoteException);
        RemoteException re = (RemoteException) cause;
        Assert.assertTrue(re.toString().contains("DeferredError"));
      }
{code}
- several lines exceed the 80 column limit, mind fixing those?
- also, the findbugs warnings

> Allow handoff on the server side for RPC requests
> -------------------------------------------------
>
>                 Key: HADOOP-11552
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11552
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: ipc
>            Reporter: Siddharth Seth
>            Assignee: Siddharth Seth
>              Labels: BB2015-05-TBR
>         Attachments: HADOOP-11552.05.patch, HADOOP-11552.1.wip.txt, HADOOP-11552.2.txt,
HADOOP-11552.3.txt, HADOOP-11552.3.txt, HADOOP-11552.4.txt
>
>
> An RPC server handler thread is tied up for each incoming RPC request. This isn't ideal,
since this essentially implies that RPC operations should be short lived, and most operations
which could take time end up falling back to a polling mechanism.
> Some use cases where this is useful.
> - YARN submitApplication - which currently submits, followed by a poll to check if the
application is accepted while the submit operation is written out to storage. This can be
collapsed into a single call.
> - YARN allocate - requests and allocations use the same protocol. New allocations are
received via polling.
> The allocate protocol could be split into a request/heartbeat along with a 'awaitResponse'.
The request/heartbeat is sent only when there's a request or on a much longer heartbeat interval.
awaitResponse is always left active with the RM - and returns the moment something is available.
> MapReduce/Tez task to AM communication is another example of this pattern.
> The same pattern of splitting calls can be used for other protocols as well. This should
serve to improve latency, as well as reduce network traffic since the keep-alive heartbeat
can be sent less frequently.
> I believe there's some cases in HDFS as well, where the DN gets told to perform some
operations when they heartbeat into the NN.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message