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 <[email protected]> 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 <[email protected]> wrote: > > > On Thu, Oct 10, 2013 at 6:39 PM, Sergey Shelukhin < > [email protected]>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 > > >
