Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> VOTE: HDFS-347 merge

Copy link to this message
Re: VOTE: HDFS-347 merge
Here is a compromise proposal, which hopefully will satisfy both sides:
We keep the old block reader and have a configuration option that enables it.

So in addition to dfs.client.use.legacy.blockreader, which we already
have, we would have dfs.client.use.legacy.blockreader.local.

Does that make sense?

On Wed, Feb 27, 2013 at 12:06 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia <[EMAIL PROTECTED]> wrote:
>> On Feb 26, 2013, at 1:51 PM, Eli Collins wrote:
>>> it doesn't seem right to hold up 347 up for Windows support given that
>>> Windows support has not been merged to trunk yet, is not in any Apache
>>> release, etc. Personally I don't like establishing the precedent here
>>> that we can hold up a merge due to requirements from an unmerged
>>> branch.
>> It is not being held back of for the windows port. It is being held back because 2246 should not be removed as part of 347; a separate jira should had been filed to remove it.
> This isn't about just having a separate jira though right?  We could
> easily pull the change out to two jiras (one removes 2246 and then
> next adds 347), they weren't separated because the goal for 347 was to
> be a re-write of the same feature (direct reads).  You commented on
> 2246 that it is a temporary workaround for 347, do you no longer feel
> that way?  Your reply to ATM made it seem like this was something that
> we'd be maintaining for a while (vs being a stopgap until 347 adds
> Windows support).