hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: ANN: hbase 0.20.0 Release Candidate 2 available for download
Date Thu, 27 Aug 2009 07:24:20 GMT
I understand your reasoning Stack. However, this project is gathering a lot of interest and
is being considered in several (many?) places. Some noobs will find bugs (???) and make embarrassing
and very public keynotes at some major conference. Some RD teams at companies considering
HBase/Bigtable as appropriate architecture might have insufficient confidence or be actually
burned into opting for something totally sub par but "stable" such as RDBMS sharding. Perfection
is not required, but a known issue affecting stability as according to JGs analysis of the
balancing issue, or which causes data loss as 1780 and 1784, must be fixed. I agree the rest
can be pushed to a point release.

   - Andy




________________________________
From: stack <stack@duboce.net>
To: hbase-dev@hadoop.apache.org
Sent: Wednesday, August 26, 2009 7:44:57 PM
Subject: Re: ANN: hbase 0.20.0 Release Candidate 2 available for download

My reasoning is that RC2 has enough 'right' about it.  Its radically better
than our 0.19 offering, as is.

The benefit is that we have a week or two less of 0.19.x and that those who
only work with released software will get the new hbase earlier.

I'm anxious to get us over this 0.20.0 hump -- yes, it will have known
defects but every release we've made has had known defects? -- and to get
the latest documentation up on our site so noobs and those whose only
interaction with the project is via hbase.org -- the marjority? -- are
using, finding bugs, and asking questions about the new rather than the
old.  I'd also like to get the 0.21 hbase focus started.

HBASE-1794 is amusing but for a fact, replay has been broken for many
releases now.
HBASE-1780 is a problem in 0.19.x
HBASE-1784 is an issue, yeah, but looks like the hadoop install is missing
hadoop-4681?

St.Ack







On Wed, Aug 26, 2009 at 8:19 AM, Andrew Purtell <apurtell@apache.org> wrote:

> There is a lot riding on getting this release right. There have been some
> serious bugs unearthed since 0.20.0 RC1. This makes me nervous. I'm not sure
> I understand the rationale for releasing 0.20.0 now and then 0.20.1 in one
> week, as opposed to taking the same amount of time to run another RC cycle
> to produce a 0.20.0 without bad known defects. What is the benefit?
>
>    HBASE-1794: Recovered data still seems missing until compaction, which
> might not happen for 24 hours. Seems like a fix is already known?
>    HBASE-1780: Data loss, known fix.
>    HBASE-1784: Data loss.
>
> I'll try to put up a patch/band-aid against at least one of these tonight.
>
> HBASE-1784 is really troubling. We should roll back a failed compaction,
> not vaporize data. -1 on those grounds alone.
>
>    - Andy
>
>
>
>
> ________________________________
> From: stack <stack@duboce.net>
> To: hbase-dev@hadoop.apache.org
> Sent: Wednesday, August 26, 2009 4:21:33 PM
> Subject: Re: ANN: hbase 0.20.0 Release Candidate 2 available for download
>
> It will take a week or so to roll a new RC and to test and vote on it.
>
> Why not let out RC2 as 0.20.0 and do 0.20.1 within the next week or so?
>
> The balancing issue happens when you new node online only.  Usually
> balancing ain't bad.
>
> The Mathias issue is bad but still being investigated.
>
> Andrew?
>
> St.Ack
>
>
> On Wed, Aug 26, 2009 at 1:04 AM, Mathias Herberts <
> mathias.herberts@gmail.com> wrote:
>
> > On Mon, Aug 24, 2009 at 16:51, Jean-Daniel Cryans<jdcryans@apache.org>
> > wrote:
> > > +1 I ran it without any problem for a while. I asked Mathias if 1784
> > > should kill it and he thinks no since it is not deterministic.
> >
> > Given the latest run I did and the associated logs/investigation which
> > clearly show that the missing rows is related to failed compactions I
> > change my mind and now think 1784 should kill this RC.
> >
> > so -1 for rc2.
> >
> > Mathias.
> >
>
>
>
>
>



      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message