On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers <a...@cloudera.com> wrote:
> 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. > This could be simpler. If HDFS-347 is configured, then use that method. If it does not work, then fall back to normal TCP reads. If HDFS-2246 method is configured the current functionality works as is. HDFS-347 overrides HDFS-2246 if both are configured. That means when configuring HDFS-2246, the user also needs to turn off HDFS-347. -- http://hortonworks.com/download/
