hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4049) Cross-system causal tracing within Hadoop
Date Mon, 29 Sep 2008 20:56:44 GMT

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

Doug Cutting commented on HADOOP-4049:

This looks much cleaner.

We need to detect incompatibility.  We currently version the transport (Client/Server) and
application (protocol) layers, but this changes the RPC layer, between those, for which we
do not currently have a version checking mechanism.  Newer clients attempting to talk to older
servers and vice versa will fail in unexpected ways.

The best way I can think to fix this is to increment the transport version (Server#CURRENT_VERSION,
even though that layer has not changed), and add an RPC-layer version field in Invocation,
so that if we ever change the RPC layer again we'll be able to.  This can just be a single-byte
field in Invocation that write() sends and readFields() checks against a constant value. 
Then, should we ever change Invocation and/or RPCResponse again we'll be able to detect it.
 Does that make sense?

Finally, is NullRPCInstrumentation needed?  You seem to accept null as a value for an instrumentation,
so I don't see why this class is needed.  If we do need such a class, then it would be shorter
to replace RPCInstrumentation's abstract methods with {}.  Less code is almost always better
with me!

> Cross-system causal tracing within Hadoop
> -----------------------------------------
>                 Key: HADOOP-4049
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4049
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: dfs, ipc, mapred
>    Affects Versions: 0.18.0, 0.18.1
>            Reporter: George Porter
>         Attachments: HADOOP-4049.2-ipc.patch, HADOOP-4049.3-ipc.patch, HADOOP-4049.4-rpc.patch,
HADOOP-4049.6-rpc.patch, HADOOP-4049.patch, multiblockread.png, multiblockwrite.png
> Much of Hadoop's behavior is client-driven, with clients responsible for contacting individual
datanodes to read and write data, as well as dividing up work for map and reduce tasks.  In
a large deployment with many concurrent users, identifying the effects of individual clients
on the infrastructure is a challenge.  The use of data pipelining in HDFS and Map/Reduce make
it hard to follow the effects of a given client request through the system.
> This proposal is to instrument the HDFS, IPC, and Map/Reduce layers of Hadoop with X-Trace.
 X-Trace is an open-source framework for capturing causality of events in a distributed system.
 It can correlate operations making up a single user request, even if those operations span
multiple machines.  As an example, you could use X-Trace to follow an HDFS write operation
as it is pipelined through intermediate nodes.  Additionally, you could trace a single Map/Reduce
job and see how it is decomposed into lower-layer HDFS operations.
> Matei Zaharia and Andy Konwinski initially integrated X-Trace with a local copy of the
0.14 release, and I've brought that code up to release 0.17.  Performing the integration involves
modifying the IPC protocol, inter-datanode protocol, and some data structures in the map/reduce
layer to include 20-byte long tracing metadata.  With release 0.18, the generated traces could
be collected with Chukwa.
> I've attached some example traces of HDFS and IPC layers from the 0.17 patch to this
JIRA issue.
> More information about X-Trace is available from http://www.x-trace.net/ as well as in
a paper that appeared at NSDI 2007, available online at http://www.usenix.org/events/nsdi07/tech/fonseca.html

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

View raw message