+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 <lhofha...@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 <yuzhih...@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) > <j...@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 // j...@cloudera.com
