hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: 0.92 RC0 Was: [jira] [Commented] (HBASE-2856) TestAcidGuarantee broken on trunk
Date Mon, 21 Nov 2011 15:01:34 GMT
+1 to lars's suggestion.  Personally, I think its pretty critical to get
the acid guarantee to actually be true. A handful of our customers want to
be able to rely on this.   Don't think you can really call it a guarantee
if you can't handle flushes....

Lars -- I'll take a look at the bulk load cases today.

Jon

On Sun, Nov 20, 2011 at 10:25 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> I have no emotional attachment to the 0.92 patch :)
>
> Seems an important change to make HBase behave in a way that can always be
> reasoned about.
> (Otherwise row updates might be atomic, but only if no flushes are
> happening, and no store files are involved in the query... that just sounds
> bad).
>
> I worked out the 0.92 patch, so we have the option to pull it in if we
> wanted to.
> If we cut an 0.94 branch soon (we will soon after 0.92RC, right :) ), then
> we can probably wait and have an "ACID and performance release".
>
> The 0.92 patch also fails some tests (see jira) that I have to check out
> tomorrow. Considering all of this I'd say, let's cut an RC without this;
> then we have a bit more breathing room to decide whether to put in a
> potential 2nd RC or into 0.94. Can talk about this at the hack-a-thon.
>
>
> -- Lars
> ________________________________
> From: Ted Yu <yuzhihong@gmail.com>
> To: dev@hbase.apache.org
> Sent: Sunday, November 20, 2011 8:52 PM
> Subject: 0.92 RC0 Was: [jira] [Commented] (HBASE-2856) TestAcidGuarantee
> broken on trunk
>
> TestReplication.queueFailover<
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/151/testReport/junit/org.apache.hadoop.hbase.replication/TestReplication/queueFailover/
> >was
> failing as recently as build 151.
>
> We might have had some luck for the more recent builds.
>
> w.r.t. HBASE-2856, if we have it in 0.92, I think the difference between
> 0.92 and 0.94 would be blurry.
>
> On Sun, Nov 20, 2011 at 8:41 PM, stack (Commented) (JIRA)
> <jira@apache.org>wrote:
>
> >
> >    [
> >
> https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153983#comment-13153983
> ]
> >
> > stack commented on HBASE-2856:
> > ------------------------------
> >
> > You fellas want this in 0.92?   I want to cut a 0.92 RC.  I have 0.92
> > tests passing up on jenkins a few times in a row now and all criticals
> and
> > blockers are in.  Should we wait?  Or should we cut the RC and get this
> > into the second RC (I"m sure there'll be one).
> >
> > > TestAcidGuarantee broken on trunk
> > > ----------------------------------
> > >
> > >                 Key: HBASE-2856
> > >                 URL: https://issues.apache.org/jira/browse/HBASE-2856
> > >             Project: HBase
> > >          Issue Type: Bug
> > >    Affects Versions: 0.89.20100621
> > >            Reporter: ryan rawson
> > >            Assignee: Amitanand Aiyer
> > >            Priority: Blocker
> > >             Fix For: 0.94.0
> > >
> > >         Attachments: 2856-0.92.txt, 2856-v2.txt, 2856-v3.txt,
> > 2856-v4.txt, 2856-v5.txt, 2856-v6.txt, 2856-v7.txt, 2856-v8.txt,
> > 2856-v9-all-inclusive.txt, acid.txt
> > >
> > >
> > > TestAcidGuarantee has a test whereby it attempts to read a number of
> > columns from a row, and every so often the first column of N is
> different,
> > when it should be the same.  This is a bug deep inside the scanner
> whereby
> > the first peek() of a row is done at time T then the rest of the read is
> > done at T+1 after a flush, thus the memstoreTS data is lost, and
> previously
> > 'uncommitted' data becomes committed and flushed to disk.
> > > One possible solution is to introduce the memstoreTS (or similarly
> > equivalent value) to the HFile thus allowing us to preserve read
> > consistency past flushes.  Another solution involves fixing the scanners
> so
> > that peek() is not destructive (and thus might return different things at
> > different times alas).
> >
> > --
> > This message is automatically generated by JIRA.
> > If you think it was sent incorrectly, please contact your JIRA
> > administrators:
> > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> >
> >
>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

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