On Wed, Feb 20, 2013 at 3:13 PM, Todd Lipcon <t...@cloudera.com> wrote:
> On Wed, Feb 20, 2013 at 3:08 PM, Tsz Wo Sze <szets...@yahoo.com> wrote: > > The reason to keep it around is that the HDFS-347 only support Unix but > not > > other OS. > > Given that this is an optimization, and we have a ton of optimizations > which don't yet run on Windows, I don't think that should be > considered. Additionally, the Windows support has not yet been merged, > nor is it in any release, so this isn't a regression. > This is a critical functionality for HBase peformance and an optimization we consider very important to have. > > I would be happy to review an addition to the HDFS-347 branch which > addresses this issue. But I don't think we should be maintaining two > codepaths for the sake of an optimization on a platform which is not > yet officially supported on trunk, especially when the old code path > is _insecure_ and thus unusable in most environments. I have to disagree. No where in the jira or the design it is explicitly stated that the old short circuit functionality is being removed. My assumption has been that it will not be removed. As regards "officially supported", we have been doing windows development for more than a year. In fact branch-1-win is being used by a lot users. Given merging it to branch-1 requires first making it available in trunk, we have been doing a lot of work in branch-trunk-win. It is almost ready to be merged as well. I am -1 on removing existing short circuit until an alternative short circuit similar to HDFS-347 on all the platforms.
