hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: HEADSUP: Working on new 0.96.0RC
Date Fri, 11 Oct 2013 21:07:26 GMT
Can you provide some detail about the test failure ?

I ran test suite for trunk on hadoop 2.2 and didn't see such failure.

Cheers


On Fri, Oct 11, 2013 at 2:03 PM, Stack <stack@duboce.net> wrote:

> Anyone tried the 2.2 hadoop that is up for vote at the moment?  I tried our
> unit tests and got these failures:
>
> Failed tests:
> testCopyTable(org.apache.hadoop.hbase.mapreduce.TestCopyTable):
> expected:<0> but was:<1>
>   testStartStopRow(org.apache.hadoop.hbase.mapreduce.TestCopyTable):
> expected:<0> but was:<1>
>
>
> testMultithreadedTableMapper(org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper)
>   testSimpleCase(org.apache.hadoop.hbase.mapreduce.TestImportExport)
>   testMetaExport(org.apache.hadoop.hbase.mapreduce.TestImportExport)
>
>
> testExportScannerBatching(org.apache.hadoop.hbase.mapreduce.TestImportExport)
>   testWithFilter(org.apache.hadoop.hbase.mapreduce.TestImportExport)
>   testWithDeletes(org.apache.hadoop.hbase.mapreduce.TestImportExport)
>
>
> testExcludeMinorCompaction(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
>
>
> testMRIncrementalLoad(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
>
>
> testMRIncrementalLoadWithSplit(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
>   testMROnTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>
>
> testMROnTableWithCustomMapper(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>
>
> testBulkOutputWithTsvImporterTextMapper(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>
>
> testBulkOutputWithAnExistingTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>
>
> testMROnTableWithTimestamp(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>
>
> testBulkOutputWithoutAnExistingTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv):
> expected:<0> but was:<1>
>   testRowCounterNoColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter)
>
>
> testRowCounterHiddenColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter)
>
>
> testRowCounterExclusiveColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter)
>   testCombiner(org.apache.hadoop.hbase.mapreduce.TestTableMapReduce)
>
> testMultiRegionTable(org.apache.hadoop.hbase.mapreduce.TestTableMapReduce)
>
>
> testScanEmptyToAPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1)
>
>
> testScanEmptyToBBA(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1)
>
>
> testScanEmptyToBBB(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1)
>
>
> testScanEmptyToOPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1)
>
>
> testScanEmptyToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1)
>   testWALPlayer(org.apache.hadoop.hbase.mapreduce.TestWALPlayer):
> expected:<0> but was:<1>
>
>
> testScanYZYToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanOPPToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanYYXToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanOBBToOPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanOBBToQPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanFromConfiguration(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testScanYYYToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2)
>
>
> testExportFileSystemState(org.apache.hadoop.hbase.snapshot.TestExportSnapshot):
> expected:<0> but was:<1>
>
>
> testSnapshotWithRefsExportFileSystemState(org.apache.hadoop.hbase.snapshot.TestExportSnapshot):
> expected:<0> but was:<1>
>
>
> Anyone else seeing this?
> St.Ack
>
>
>
> On Fri, Oct 11, 2013 at 10:05 AM, Stack <stack@duboce.net> wrote:
>
> > On Thu, Oct 10, 2013 at 6:39 PM, Sergey Shelukhin <
> sergey@hortonworks.com>wrote:
> >
> >> >Can we agree if the IT tests are green for a certain number of runs in
> a
> >> row, then it's stable?
> >>
> >> What do you mean by IT tests are green? Ours are mostly green lately
> >> (except for recently fixed bugs).
> >> Can you please share some investigation details? Maybe file bugs with
> >> description of symptoms, like logs and stuff; are you sure you are
> hitting
> >> 9696 in particular?
> >>
> >
> > We've been trying to keep up HBASE-9696 w/ ongoing notes.  We should do
> > better for sure but big picture is that we have evidence that what is in
> > HBASE-9696 is an improvement over what we have now having had two
> sustained
> > runs w/o data loss.   The fix is needed so we can do long-running
> hbase-it
> > suites; w/o it we were just crash-landing a few hours in.
> >
> >
> >> 9696 is a very big patch too, it can introduce more bugs and will
> require
> >> more fixing.
> >> We do need to have some deadline where large/risky changes cannot go
> imho.
> >>
> >>
> >>
> > Agree but after reviews, I do not know how to avoid it (see 9696 and its
> > RB)
> >
> > I suggest we commit hbase-9696 as is since it an incompatible change with
> > its introduction of two new states, states that we do not seem to be able
> > to do without.  Then I cut an RC.  If further issue in 9696, we can fine
> > tune/bug-fix post release.
> >
> > On another note, a rig run that has been going for almost 24 hours has
> > gone further than any run of the last few weeks.  That is good.
> >
> > Let us know if need any more info/insight.  Almost there.
> > St.Ack
> >
>

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