On Wed, Feb 20, 2013 at 4:29 PM, Chris Douglas <cdoug...@apache.org> wrote:
> Given that HDFS-347 is a strictly better approach, once committed, > there will be ample motivation to add support for other OSes and > remove HDFS-2246 entirely. Nobody is confused about this. There's > ample precedent for retaining obscure, clumsy features as a temporary > stop-gap (e.g., service plugins, opaque blobs of bytes in Tasks, > configurable combiner semantics). What's the virtue of insisting on > removing this? Unless there was a lot of follow-on work, HDFS-2246 > doesn't look like a lot of code... > Though it's not a ton of code, I think that having to support a more complex fallback path (i.e. try the HDFS-347 method, then fall back to trying the HDFS-2246 method, then fall back to doing normal TCP reads to the local DN) will make the code quite a bit hairier for little added benefit. How about this proposal for a compromise: Given that the only substantive concerns with HDFS-347 seem to be about Windows support for local reads, for now we only merge this branch to trunk. Support for doing HDFS-2246 style local reads will be removed from trunk, but retained in branch-2 for now. Only once someone adds support for doing HDFS-347 style local reads which work on Windows will we consider merging HDFS-347 to branch-2. This should ensure that there's no feature regression on branch-2, but also means that we will not need to maintain the HDFS-2246 code path alongside the HDFS-347 code path indefinitely. -- Aaron T. Myers Software Engineer, Cloudera
