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-4213
Date Thu, 15 Sep 2011 15:33:08 GMT

> From: Todd Lipcon <todd@cloudera.com>
> If a feature doesn't properly handle error conditions, it shouldn't be
> committed, IMO.

This is my concern as well. I had initially given the feature a +1 to get it in so further
development can be done, but upon further consideration (and Todd's code review) I'm concerned
it won't be useful in practice as currently implemented.

Attempting a schema update would require a completely healthy cluster and no failure could
occur during that time. In other words, the cluster would have to be quiesced first. That
is not practical, so the feature is not useful.

My recommendation is to begin adding test cases that test RS and ZK quorum peer failures happening
while the schema update is in progress, and insure that failures are handled and the update
process recovers and succeeds. Once there is a set of such tests we can evaluate their coverage
and introduce the feature. It would still be risky, but there would be some basis for believing
it to be practical.

Best regards,

   - Andy

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

>From: Todd Lipcon <todd@cloudera.com>
>To: Ted Yu <yuzhihong@gmail.com>
>Cc: Andrew Purtell <apurtell@apache.org>; Subbu M Iyer <msiyer@gmail.com>;
>Sent: Wednesday, September 14, 2011 11:57 PM
>Subject: Re: HBASE-4213
>On Wed, Sep 14, 2011 at 2:51 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>> Todd/Andy:
>> Instant schema change is an important feature.
>> Can you let us know the criteria for HBASE-4213 to graduate ?
>> Does HBASE-4370 have to be implemented ?
>In my opinion, the criteria is the same as any other. Reviewers should
>be convinced it doesn't introduce bugs or APIs we don't want to
>maintain, and the feature should be usable by ordinary folks. There
>should also be sufficient testing including fault scenarios. If a
>feature doesn't properly handle error conditions, it shouldn't be
>committed, IMO.
>Todd Lipcon
>Software Engineer, Cloudera

View raw message