hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: HBASE-1730 and HBASE-4213
Date Fri, 19 Aug 2011 01:05:08 GMT
> Using zookeeper to record transient state is Andy's favorite choice.


Ted, thank you for the consideration!
 
Best regards,


- Andy


Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)


----- Original Message -----
> From: Ted Yu <yuzhihong@gmail.com>
> To: dev@hbase.apache.org
> Cc: Subbu M Iyer <msiyer@gmail.com>; nileema.shingte@gmail.com
> Sent: Thursday, August 18, 2011 5:53 PM
> Subject: Re: HBASE-1730 and HBASE-4213
> 
> I prefer choice A below.
> 
> Let's vote on which implementation is the better approach.
> 
> My vote is for 4213. Subbu implemented hbase-451 and has deep understanding
> of related code.
> Using zookeeper to record transient state is Andy's favorite choice.
> 
> Cheers
> 
> On Thu, Aug 18, 2011 at 5:29 PM, Todd Lipcon <todd@cloudera.com> wrote:
> 
>>  In my opinion we have three options:
>> 
>>  (a) have the two contributors work together on a single JIRA
>>  (b) factor out what's common between their approaches into a new JIRA,
>>  then let them proceed independently
>>  or (c) let them proceed independently, and whichever one reaches a
>>  suitable commitable state first, we go with
>> 
>>  If they both become committable around the same time, then we should
>>  go to benchmarks as well as comparisons of which codebase seems more
>>  maintainable.
>> 
>>  -Todd
>> 
>>  On Thu, Aug 18, 2011 at 4:23 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>>  > Hi,
>>  > Due to lack of coordination, HBASE-1730 and HBASE-4213 try to 
> implement
>>  the
>>  > same feature at roughly the same pace.
>>  >
>>  > I want to hear your opinion on how we should plan to move forward with
>>  these
>>  > two JIRAs.
>>  > One possibility is to provide two policies, one accommodating each 
> JIRA.
>>  But
>>  > that requires even more work.
>>  >
>>  > It would be nice if we can have some performance numbers for both
>>  > implementations on comparable cluster(s).
>>  >
>>  > Cheers
>>  >
>> 
>> 
>> 
>>  --
>>  Todd Lipcon
>>  Software Engineer, Cloudera
>> 
>

Mime
View raw message